Hacker News Reader

Comment by lexicality | Hacker News Reader

> Second, not every change needs a great commit message. If a change is really minor, I would say minor is an okay commit message!

It's very hard to rank them, but very high on my list of things that make me want to send people actionable threats is when I'm searching down the history of a bug to figure out if it was a deliberate change that had unexpected consequences or just a mistake is when the git blame path ends on a commit like this.

I don't care how minor you think your change is, if you're working on something collaboratively you need to express intent in your commit messages!

View on HN

> if you're working on something collaboratively you need to express intent in your commit messages!

100%! And if somebody cannot communicate the intent, there is a high chance they don't understand fully what they just did.

> If a change is really minor, I would say minor is an okay commit message!

This has got to be the author fishing for reactions, right? My reaction, were I on his team, would be to revoke commit privileges.

> if you're working on something collaboratively

If I'm working on something "by myself", I'm really collaborating with my future selves, who will appreciate the information that I'll forget after the next context switch.

I think the authors point is that some changes are so minor that elaboration is not required, like changing indentation.

Elaborate commit messages are great, and most people write commit messages that could be more elaborate.

But most people also tend to squash several changes together, because it's easier.

Being overzealous about writing elaborate commit messages for minor cookies is IMHO probably counter productive.

No change is minor enough that you don't need to explain what it does.

If the commit message is "fix indentation" then I will ignore it and skip over it while searching the commit history. If it's "minor" or "fix" then I have to open the commit and look to see what it actually is.

These "minor cookies" add up rapidly.

(side note, people that squash important changes together are also on The List)

Let's not forget people that commit trailing whitespace, or different line-endings.

Can we put those on a separate List?

To be fair, we've got computers (CI, pre-commit hooks) that can stop that.

To be pragmatic, the number of times I’ve had to fix or outright create CI for other teams because they didn’t bother to add these basics is too damn high.

For anything with my team (or personal projects), where I can be guaranteed everyone understands exactly what I’ve set up, I add a pre-commit hook to fix minor linting issues and then add the change to the commit. If black, tf fmt, shfmt, etc. can just fix the problem, then do so, and don’t bother asking me if I’m sure.

I love the ‘merge commit for my feature branch with 100 commits, but squash for merging release branch to master’ type.

It’s as if a thousand commits cried out in anguish and were suddenly silenced.

> I think the authors point is that some changes are so minor that elaboration is not required, like changing indentation.

Is the change _just_ changing indentation or is it changing something else which is hidden by a bunch of indentation changes?

The difference between a commit message like "reindent" and "." is that the former makes it clear that the change is intended to be completely superficial and (unless you're writing python) should have no impact on anything.

Now the person who wrote that commit message may be lying, or may have made a mistake, but, with even a commit message such as "reindent", it's much easier/faster to approach the issue if your bisect lands on such a commit message as you can go straight for "well let's normalize both versions to see if there's an accidental change hidden in here" rather than getting frustrated trying to figure out what the commit was about.

> But most people also tend to squash several changes together, because it's easier.

Don't.

I also disagree with the author of the article about having an unclean history, it's not that hard to keep a clean history and, combined with actually properly splitting and isolating changes, makes it much easier to review the code. Proper use of git isn't solely centred around making bisect work.

This. If it looks like my change is blowing up in prod at 4 AM, and I didn’t write down what I was trying to do, you are absolutely entitled to wake me up and demand an explanation.

Reply on news.ycombinator.com