3 ms·

"Commits ordered by when I figured out a bug" has a lot less value than "Commits where changes are grouped by semantic logic". Stuff like git rebase don't work

by rtpg 7y ago

"Commits ordered by when I figured out a bug" has a lot less value than "Commits where changes are grouped by semantic logic". Stuff like git rebase don't work so well if you have a bunch of WIP busted commits as well. Maybe you don't commit that often, but people I work with (and myself) commit pretty often so it's easy to have just outright mistaken git commit messages like "fix X" followed by "actually fix X". going through a rebase to have "fix X" mean "fix X" will be great for the future debugging session with a git blame.

clktmr 7y ago
In addition, it makes cherry picking bugfixes to older releases much easier.
stonogo 7y ago
On the other hand, "fix x" followed by a couple lines of rationale, then "actually fix x" with a discussion of why the previous fix was wrong is more useful to someone trying to understand x.
- rgoulter 7y ago
  I think the discussion is valuable. I think adding those insights to a wiki 'Pitfalls' page or whatever is valuable. From the top of my head, the cases where I'm looking at Git logs are: 1. Code Review. Most of the time I'm reviewing code is looking at a diff. But obviously one of "fix" and "actually fix" is redundant. A clean history also benefits if I want to focus in on one of the commits. 2. Annotation/Blame. If I'm debugging through some issue and looking at older changes, it's nice if coupled changes are in the same commit. A warts-and-all history has some advantages over rewriting git history (e.g. you could find patterns of where "actually fix" happens and try and improve those), but rewriting history makes the log a better communication tool.
- rtpg 7y ago
  Yeah this is legitimate I think it’s maybe the difference between emotional truth and literal truth. The emotional truth is the valuable one so rebasing (which doesn’t mean squashing to one commit!) can mean you can clean out the noise and get something valuable.

by rtpg 7y ago

clktmr 7y ago

In addition, it makes cherry picking bugfixes to older releases much easier.

stonogo 7y ago

On the other hand, "fix x" followed by a couple lines of rationale, then "actually fix x" with a discussion of why the previous fix was wrong is more useful to someone trying to understand x.

rgoulter 7y ago
I think the discussion is valuable. I think adding those insights to a wiki 'Pitfalls' page or whatever is valuable. From the top of my head, the cases where I'm looking at Git logs are: 1. Code Review. Most of the time I'm reviewing code is looking at a diff. But obviously one of "fix" and "actually fix" is redundant. A clean history also benefits if I want to focus in on one of the commits. 2. Annotation/Blame. If I'm debugging through some issue and looking at older changes, it's nice if coupled changes are in the same commit. A warts-and-all history has some advantages over rewriting git history (e.g. you could find patterns of where "actually fix" happens and try and improve those), but rewriting history makes the log a better communication tool.
rtpg 7y ago
Yeah this is legitimate I think it’s maybe the difference between emotional truth and literal truth. The emotional truth is the valuable one so rebasing (which doesn’t mean squashing to one commit!) can mean you can clean out the noise and get something valuable.