Hacker News Reader

Comment by ssijak | Hacker News Reader

Do people actually check commit history in detail so often that they absolutely find so much value in ultra clean commit history? I never understood that obsession with 100% clean history.

View on HN

When I'm hunting a mistake (even/especially my own) finding the commit that introduced the bad line via blame and then looking at that specific diff is extremely handy. Also being able to bounce back and forth between the first broken one and the one before running tests while I work out exactly what I messed up and how.

I wouldn't say I put the effort in to get to 100% clean but something like 95% clean makes future me significantly less enraged at past me's mistakes.

You don’t even have to do archaeology to benefit from clean commits, it helps tremendously during review too. How do you review nontrivial changes without splitting them in digestible chunks?

Yes, absolutely. Writing out a change log when you have clean commit history is a trivial task. Doing so when it's not clean, can be arduous and take hours, and then still end up being inaccurate.

I also frequently try to find when some bug or change was introduced in the get history, so that I can understand why it was done through the context. Context. When it is just thrown in some random commit that doesn't even have much of a commit message, it is utterly useless. When it is part of a commit that is atomic and targeted at one thing, it is trivial to see why it was done. Even when the comment isn't super helpful (which is common despite intentions, because predicting the future and what will be useful in the future is very difficult) it's still valuable because you can see the code in its full context and it's often clear what it's doing.

So yes, I am a big believer in clean commit history with atomic, single commits that represent the task someone was doing. For example, If it was a bug fix, then the bug fix will be in its own commit with a commit message describing the bug that is being fixed.

It's self-reinforcing. If commit history is reasonably clean, the barrier to doing code archeology is lower, so you reach for it more often. And if you do code archeology often, you develop a better sense of what's a clean commit history and what makes commit messages useful.

The need for code archeology depends on a project. When you writing a lot of new code it's probably less important than in a legacy thing where most changes are convoluted tweaks made for non-obvious reasons.

Do people wash their hands 15 times a day so that they absolutely fine so much value in getting rid of the bugs?

The answer is: some do, some don't.

Yes, absolutely.

If I'm doing a `git blame` or digging through the annotate gutter in GitHub I prefer to find the appropriate commit context, not a commit with title "typo" or "oops" or "trying something" or "WIP".

In the latter case you can still do the `git log` archaeology to find the actual context but I'd rather not.

Some teams will squash all merges to avoid this problem, but why not have the best of both worlds by merging relatively clean branches?

I do. To learn a code base it before tremendously, also to find what happened and why things were done it is off great help. I don't need it every day but I routinely do git archeology.

Doesn't have to be 100% clean, but history has tremendous value to me. Often the most important question for me when fixing a problem is "was this intentional" (aka did that guy (who left 10 years before I arrived) know what he was doing?).

As far as I remember, I've had to check history for about 2/3 of bugs I've fixed.

In a perfect world each system would be documented and tested well enough that correctness could be derived from first principles, but we do not live in a perfect world :(

Yes. When doing `git bisect`, for example.

Yea teams that have poor tracking and no PR practices.

Only in codebases that have good commit history

Reply on news.ycombinator.com