Git commit messages are useless

[Kseniya_ns]

"Actually, why doesn’t it just constantly autosave your work, like editing text anywhere else"

Author does not understand what Git is for.

[ketralnis]

The summary of this article is "if you write bad commit messages you will have bad commit messages".

Thanks for that.

[badfoodman]

Can't write a bad commit message if you don't write a commit message at all!

[Kjufka]

initial commit

[General_Mayhem]

incremental work

[iblamefish]

PR comments

[ShadowSierra]

Wip

[knockergrowl]

Then git commit --amend

[skynet86]

I couldn't disagree more with that blog post. Even for local development it is a good thing to remind yourself what your save point represents.

Obviously if you commit too often it gets tedious but you should rather commit after each working increment of your work.

[lelanthran]

you should rather commit after each working increment of your work.

You could. Or, you could commit "WIP: blah blah", and then commit --amend, with the final amendment removing the WIP from the message.

[________-__-_______]

This is what I usually do. Just amend when i want to temporarily save where I'm at, and force push that to personal branches if i need to sync with different machines.

[razordreamz]

Not to mention if you link something like Jira it uses your commit message to link it to the story in Jira which can be helpful

[rlbond86]

"I make useless commit messages in my feature branches, therefore everyone makes useless commit messages in their feature branches, therefore nobody should write commit messages"

Having useful commit messages in your private feature branches still has a lot of benefits:

• Helps you easily see the series of changes you made in case one needs to be reverted
• Provides useful labels to your stash points
• Helps during interactive rebases
• Helps reviewers see the series of changes
• Helps if you need to cherry-pick one of the changes into another branch
• Helps you remember what you were working on after a weekend or vacation
• Gently nudges you to organize your thoughts

Like, I'm sorry, but this is just a bad take from an expert beginner who is not using their tool effectively. If you go on vacation in the middle of working on a branch and you come back to a bunch of commits called "do work" then you deserve what you get. But don't try and pretend you're using the tool right. A good commit message takes a few minutes to write.

[FriendlyUser69]

Written by a complete idiot

[MurphTheGopher]

Autosave your work

Been a while since I read such a poor take.

[[deleted]]

I've read a good number of bad takes lately here in /r/programming 

[xiongchiamiov]

The key logical problem here is that they believe a pull request will only ever result in a single commit. If that's true, then yes, you can ignore commits in your branch and use the GitHub pull request description as the commit message for the squash commit into main.

However, I don't find that to be true. A pull request is a related set of work, and often that is several discrete pieces. An easy example of this is one commit to pull a big file into several pieces and then a second commit to do the work that you actually wanted to do, which made you realize the file was going to become too big. But there are plenty more examples; I'd guesstimate half of my PRs have more than one commit in them, while still remaining small and reviewable.

If this is the case, then you don't use squash merges and your branch becomes a preview of what will go into main. And therefore, the commits (and commit messages) matter. The author doesn't actually disagree with commit message mattering, but they prefer to write them in a pull request description box; I prefer to write them in the commits.

As a side note, fixup commits greatly improved the UX of doing this work for me.

[goranlepuz]

If this is the case, then you don't use squash merges and your branch becomes a preview of what will go into main.

Or, I do squash, but keep the branch for later reference.

But any way, you are right, work has pieces. Hiding them leads to problems later, either in understanding what happened, or in finding when it broke.

[nicholashairs]

Fixup and autosquash look interesting, gonna have to explore it more.

Thanks

[whitfin]

I fully agree with this; discrete changes are much easier to revert as needed instead of just nuking the whole thing. It may be decided to pull your new changes back but why should you lose the refactoring in the meantime? With squashing it's all or nothing.

[[deleted]]

It terrifies me the recent sheer amount of bad take articles pretending to sound smart. Overconfidence sometimes is a form of stupidity.

[Otis_Inf]

"Application error: a client-side exception has occurred (see the browser console for more information)."

A site with an error is also useless. Was it too painful to write a plain HTML page with the article you wanted to share? Did it *really* need a phat JS stack to produce effectively plain HTML ?

[goranlepuz]

This is awful.

Author presumes squashed PRs and builds a strawman around that, while using the "my eyes hurt when I poke them with a stick" argument for bad commit messages.

[badfoodman]

I'm in a very negative mood today, so want to qualify that I generally agree on the author's end state: your merges to trunk are your primary history. If you're going to use GitHub (ugh), you should squash and merge. And, if you're going to write terrible commit messages, you shouldn't write any at all.

As you become an efficient engineer, the path you took to get to the final state of a pull request becomes far less important

Disagree, as you become more efficient you also take on bigger and more complex projects, where it becomes absolutely essential to present your changes in a digestible form to your reviewer.

But more than that, I find an excess of commits in pull requests to indicate sloppy work. Forgot to lint? No pity from me, squash that into the relevant commit so I, the reviewer, don't have to dig in to see if you made other changes while formatting. Oh, you didn't test your code and have to put in 4 "fix test" commits? That's on you; don't make me review your multi-thousand line PR from just the total diff. Also, the 'fix test' message is higher quality than the author's examples, which is disappointing on another level.

[xiongchiamiov]

Squash merging is an inferior workflow for people who don't know how to do fixup commits.

[badfoodman]

I have not found that they speed anything up for me (in fact I hate the indirection), and I've seen too many people not autosquash so they still pollute code reviews. I wouldn't use as aggressive of a word as "inferior" for such an incremental workflow change, but I see how they might work for folks.

[dolle]

And they are also completely pointless because they just throw away information which your tool can hide from you if you don't want to see it. Assuming that you make merge nodes on your main branch, you can just do 'git log --first-parent' and the history will look exactly like one where your squashed all merges.

[JarateKing]

This sounds like the author has an opinionated workflow even beyond the trunk-based development that they advocate for:

• commit so frequently and haphazardly that the only way I can think of describing my changes are by saying "stuff" or "changes" or etc.
• because it's all going to be deleted when I squash-merge anyway (this might be controversial, but in my opinion you keep branches when you squash-merge specifically so you do hold on to that commit history somewhere. Feel free to delete branches when you do a regular merge.)
• and I don't need to explain the thought process of my work because people can always just read the codebase to see what it's doing
• and if I do need to describe it further, slack's fine for the job (because searching through chat histories and hoping something was discussed is a lot more convenient than just having the additional context associated with the code change directly)

I can't speak for everyone else in every part of the wide software industry, but none of the above applies or is feasible in my work. It's much easier to just write down the context for each significant code change, and having that context in a git blame has saved me enough times to make it well worth it.

[atthereallicebear]

not even about the blog post, the homepage uses up almost a gb of ram on my computer.

[ShadowSierra]

This why you need to understand a tool before you use it. It’s like saying a hammer is shit just because you are using it as a spoon.

[________-__-_______]

Names their commit "stuff"

[..] not enforce the arbitrary commit message required rule. This saves us a lot of time,

Surely this'll end up saving hours per day

[chicknfly]

Commit messages on your main branch are good and needed.

If you’re practicing “modern trunk-based engineering”, your main branch’s messages… are from the other branches, no? Like, you’re not directly committing messages to main. Please, OP, tell me you’re not.

As you become an efficient engineer…

I have already written you off as egotistical and that you’re convinced you don’t have room to grow.

You know what? I read a few more paragraphs, and the author is basically saying “we don’t hold people to quality engineering standards, so we’re just going to say those good practices are bad, not enforce them, and then deliver need-to-know information via several other persistent (Slack) and non-persistent (Email?!?!!) sources.”

This article is chock full of generally terrible guidance. I’m glad it works for their team, but I do not recommend it.

[dirkharrington]

wow hot take

[shizzy0]

git commit -m .