Hacker News Reader

Comment by rubyist5eva | Hacker News Reader

I have a guy on me team that commits basically every 5 or so lines. Hell have a 30 line bug fix spread across like 20 commits because he never goes back and cleans up those small commits that get changed afterwards, not to mention he’ll merge the development branch into it numerous times and never rebased. It’s absolutely infuriating reading through git logs that involve his stuff.

His commit messages are equally maddening - “change this variable to 5”, “fix broken spec”, “change variable to 7” ad nauseam…

View on HN

This is kind of like me except I list the component, function or class I did the change in. We do a squash on each branch before merging anyway

You're lucky that you have him.

Not really because none of his commits have any context on what the purpose any of his changes are actually for. He never describes why he does anything, just that he is changing something (which is obvious from the code).

It's the git equivalent of "useless comments" like `int x = 10; // set x to 10`

In my opinion, commits aren't a record of why. They are a record of what. Commit messages a shorthand of what for easier skimming.

Comments answer why (and even 'what' is fine if the code is difficult.)

But simple rules like that always have exceptions.

Assuming you squash the PR and view it holistically, what's the issue?

PRs dont' squashed, nothing gets rebased and only merge commits are allowed for anything non-local. It adds noise to trying to figure out why changes are made because the commit messages only explain what was changed, not the purpose or context.

If you're not squashing your PR's I can see the problem, but I also see the other problem.

Do you think squashing the PR is the superior choice? Why?

Because then you don't see all those minor little changes and can view the PR holistically. I don't typically find that viewing the changes in chronologically order buys much, it's not the order I care about, it's the final changes themselves that have an impact on the system, especially when those changes could be transient (changing something in commit #1, change it back in commit #3). There's a larger load to comprehension with a squashed commit, but it shouldn't be THAT large, and it removes all the temporal noise.

It also makes tracing the historical "why" of a change easier to understand. If you don't squash it's a random change in the log, if you do squash then it's "adding feature x".

Reply on news.ycombinator.com