There have been multiple accounts created with the sole purpose of posting advertisement posts or replies containing unsolicited advertising.

Accounts which solely post advertisements, or persistently post them may be terminated.

ConstantPain ,

At least none of it is WIP…

Buttons ,
@Buttons@programming.dev avatar

Meh. At least you know “WIP” means you shouldn’t expect that particular commit to work.

ConstantPain ,

It just has to work enough.

ryannathans ,

Perhaps, but there will a bunch of TODO comments so pick your poison

oeLLph OP ,

There are some, but not in the picture 🙃

cupcakezealot ,
@cupcakezealot@lemmy.blahaj.zone avatar

kinda like on google play how it says “what’s new: no information from the developer” or “what’s new: we regularly update our app to fix bugs, improve performance and add new features”.

kaotic ,

Every one is using AI to make funny pictures. This is what they should be using it for. Look at my diff, generate a commit message.

andnekon ,

If you don’t know what you’ve done within a commit, it probably shouldn’t be a single commit, with or without AI Although if you’re talking about using AI to make funny commit-messages…

locuester ,

Ok Eugene, we get it.

Daxtron2 ,

Doesn’t mean you can’t use text inference to make your messages better

AnExerciseInFalling ,
Daxtron2 ,

We’re doing that too :)

time_fo_that ,

About what my coworkers do but even worse with stuff like “save” and “fix”

catlover ,

git commit -m ‘initial commit’

git commit --amend

git commit --amend

git commit --amend

git commit --amend

git commit --amend

Sage1918 ,

It’s all fun and games until a git push slides in between…

EmergMemeHologram ,

Always use --force, far fewer errors that way.

I also use git reset instead of merge. It keeps history more linear.

Sage1918 ,
  • –force-with-lease
bitwolf ,

Maybe they tastefully squash merge when they pr/merge into main.

oeLLph OP ,

The don’t… 😭

Cwilliams ,

<span style="color:#323232;">do_the_thing() {
</span><span style="color:#323232;">  git commit -am "$(date)"
</span><span style="color:#323232;">  git push
</span><span style="color:#323232;">} 
</span>
Justas ,
@Justas@sh.itjust.works avatar

I remember making a bunch of fixes and calling them after Star Wars movies with the thing I’m fixing or what was broken as the noun.

onlinepersona ,

Could you give an example? “Star Wars: The Bug Fix”?

CC BY-NC-SA 4.0

Justas ,
@Justas@sh.itjust.works avatar

The upload menace

Attack of the zero

Revenge of Apache

A new filter

The loop strikes back

Return of the analytics

onlinepersona ,

😂 these are great, thanks!

CC BY-NC-SA 4.0

hakunawazo ,

So you were part of the git clone wars?

Justas ,
@Justas@sh.itjust.works avatar

Ah the historian.

mindbleach ,

What The Commit provides a list of all-purpose messages to randomly select between. Would these be better?

oeLLph OP ,

🫣 $(rm -rvf .)

vbb ,
@vbb@lemmy.world avatar

Good opportunity to say how annoying are update notes like “We are continuing to improve our application. We fixed a couple more issues to make it more stable”. Corporate style, uselessness and the fact that this update can contain some stupid redesign is disgusting.

TurtleTourParty ,

“We are constantly improving our application. Please keep updates turned on.”

popcar2 ,

I’ve reached a point where I avoid these types of updates. An update post like that either means nothing important changed or they’re up to something.

A while ago I saw that style of patch notes, updated an app, and suddenly I can’t use it anymore because it got limited to a maximum of 2 devices. Another time I updated an app putting a harmless “we improved the user experience” message, they put dark mode behind a paywall. This isn’t counting the number of times an app got redesigned to make the user experience worse for no reason. Maybe they wanted to justify hiring 5 UI/UX interns in that quarter or something.

The patch notes look harmless, but my god, they are usually up to something.

MajorHavoc ,

Yeah. I do the same. That “we are making improvements” text is corporate for “we don’t have anything remotely close to change management or quality assurance”.

clearleaf ,

I’m done with programs that need meaningless updates like this every day. All my patience for that was used up with flash and java.

jjjalljs ,

My commits when merged into main generally read like

[Ticket-123] Summary of what was done. Eg: Return user foo property in bar endpoint

  • update bar view to return new foo key
  • update foobrinator to determine foo property
  • update tests

It takes an extra minute or two but it’s more informative for the team / future me.

onlinepersona ,

Mine look similar except the body is mostly “the X was doing Y, but it should’ve been doing Z” or “the docs say bla, $link”. I try to separate the individual “update A to do B” in separate commits, but sometimes it just isn’t possible.

CC BY-NC-SA 4.0

jjjalljs ,

We squash everything (and rebase rather than merge) so I don’t worry much about the individual commits. I like that main is pretty concise and doesn’t have a ton of work-in-progess stuff in the log.

onlinepersona ,

We are mortal enemies you and I 😄 I’d much rather have a descriptive commit history than huge commits which make git blame meaningless. Function over beauty for me.

CC BY-NC-SA 4.0

jjjalljs ,

A nemesis! I’m pretty lucky I guess that no one at my workplace has strong git opinions that differ

Do you have multiple people’s commits being squashed together? Or how is blame being made useless for you? I’m at a rather small company where generally it’s just one person working on a thing at a time. The blame will point to their squashed commit that, if they wrote a good message like the top of this thread, will give you a lot of context.

onlinepersona ,

Imagine finding a bug in angularjs, doing a git blame and finding this commit

feat(module): new module loader

211 changed files with 1,051 additions and 1,242 deletions.

AngularJS isn’t even the worst offender. I’ve seen backports of multiple fixes getting squashed into one commit for “a clean history” with all the useful commit messages ending up in one commit.

Many user stories I’ve seen implemented in a sprint take multiple days to write. Sometimes they have 5+ commits with a multitude of files changed and (if done right) each commit has an explanation why something was done or at least what was done. Having a granular view of changes also allows finding related changes quickly with less code to read.
If someone changes the implementation of a function call in one commit and it introduces a bug, it’s nice to have only that change instead of the entire class with it and changes in other files too. Additional changes mean now you have to read through more code to be sure that the function implementation change was not done due to a modification of the class or whatever else was changed which might be the actual source of the problem.

IMO squashing commits has its uses. It’s a tool in a toolbox, but it’s not the only tool.

CC BY-NC-SA 4.0

jjjalljs ,

That angular commit message is a crime.

My squashed commit messages typically enumerate everything I changed and why.

IMO squashing commits has its uses. It’s a tool in a toolbox, but it’s not the only tool.

I think we agree on this.

One case that has come up for me several times: working on a feature, committing as I go. And then I realize some of what I did won’t work or isn’t what product actually wants. Leaving those commits in the history that show the function doing the wrong thing would be misleading. Especially if that was never actually in production or left my local machine.

I guess I have an unspoken belief that every commit on main should work, but you could achieve that with tags instead.

I was recently spelunking to try to find why something in old code was the way it was. I found the commit where they changed the line, but it was orphaned from the larger context. The message didn’t say more than like “change field from footype to bartype”, but not why. So I had to try to piece together what other changes were part of this change. If it had been a single commit that showed them like adding the new field, new model, and whatnot, it would have been clearer to me that those things all go together.

marcos ,

And I’d bet stuff is still broken!

MajorHavoc ,

Yeah. Definitely. If it was fixed there would be a commit with log ‘works now. WTF?!’

neurospice ,

Could be worse:


<span style="color:#323232;">git commit --allow-empty-message -m </span><span style="color:#183691;">""
</span>
solivine ,
@solivine@sopuli.xyz avatar

When there’s a limit to the size of a commit message it does make it difficult to actually list all the changes, so sometimes this is all you can write.

I know in theory you’re meant to commit little and often, but in practice it doesn’t always work out that way.

PuzzledBlueberry ,

Even if you have a big commit, you can always write something more descriptive than this. And commit messages can be huge, so the limit shouldn’t be an excuse to write a useless message.

ekky ,

For those wondering how to exceed the 70 (80) recommended character limit and still follow best practices:

  1. Write the title on the first line, keep below 70 characters.
  2. Make two (2) newlines
  3. Write one or more descriptive paragraphs.

The first line will be shown as commit message, and the full text can usually be viewed by checking out the commit. Sentences can span multiple lines, but try to keep the line length below 70 characters for best readability.

This off the top of my head, so feel free to correct me if I’ve misremembered the best practices.

r00ty Admin ,
r00ty avatar

I generally write a single line summary and then a list of the specifics like:

Did stuff (except more detailed than that)
 - The first thing I did
  - Maybe some more detail about the first thing because there's a rationale to explain
 - The second thing I did
 - Third thing

Etc.

TxzK ,

Commit messages of my personal projects are filled with just “fix”. Life is too short to write a proper commit message

  • All
  • Subscribed
  • Moderated
  • Favorites
  • [email protected]
  • random
  • lifeLocal
  • goranko
  • All magazines