3 ms·

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 obsess

by ssijak 2y ago

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.

baruch 2y ago
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.
freedomben 2y ago
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.
playingalong 2y ago
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.
jcon321 2y ago
Yea teams that have poor tracking and no PR practices.
asqueella 2y ago
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?
mst 2y ago
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.
PhilipRoman 2y ago
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 :(
chippiewill 2y ago
Only in codebases that have good commit history
cryptonector 2y ago
Yes. When doing `git bisect`, for example.
syncsynchalt 2y ago
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?
borrow 2y ago
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.

by ssijak 2y ago

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.

baruch 2y ago

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.

freedomben 2y ago

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.

playingalong 2y ago

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.

jcon321 2y ago

Yea teams that have poor tracking and no PR practices.

asqueella 2y ago

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?

mst 2y ago

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.

PhilipRoman 2y ago

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 :(

chippiewill 2y ago

Only in codebases that have good commit history

cryptonector 2y ago

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

syncsynchalt 2y ago

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?

borrow 2y ago

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.