Do you have a case where seeing all the small changes I made during development is helpful for fixing bugs and issues in the future? I would have thought it is rarely useful, and often actively unhelpful.
Let's say I make a change in three steps: I rename all uses of X in the codebase, I remove the Y component, and I fix bug Z. To me, this should be three commits: X, Y, and Z, one for each of the changes.
But to get to the final point, I probably haven't done that in only three steps. What I've probably done is I've tried out change W, but that didn't help at all so I abandoned it, then I started doing Y, realised that I needed to do X first for Y to make sense, so I switched and did X, then I finished Y, then I could do Z. Then I realised that while doing X I'd forgotten some stuff so I finished that off, then I realised that the tests weren't passing because part of Y wasn't finished. Then I pushed everything and the reviewer pointed out that while fixing Z, I'd left some code commented out and I needed to remove it properly.
Long-term, which of these sets of changes would be most useful? Surely the first one: it shows my aim while making changes, it is clearly bisectable, and it is divided into clean units of work without overlap or having those units intermingled. As a future developer, I can run `git blame` or equivalent and clearly see why each line of code was changed, and for what reason.
Whereas with the latter case, bisecting the codebase will stumble on all the intermediate situations where a test failed or the code didn't compile or whatever, because bad states during the development process are now part of the permanent history. And it'll produce spurious results when I try to annotate a file: the last time this file was changed was because I temporarily commented out this line and then immediately commented it back in again, how do I see only the changes that made a meaningful impact to this line?
In my experience, recording these sorts of "fixup" changes permanently in the history has never been useful. Having clear, precise commits that each do one thing: definitely, yes, this is a fantastic tool. But being able to go back in time with such granularity as to see when you broke a test and then fixed it in review? Or when you started out doing one change and then did something else instead in a different order? I have never found that level of detail useful, and it is often makes things harder when I'm trying to focus on the significant commits and changes and just want to filter all of those out.
Let's say I make a change in three steps: I rename all uses of X in the codebase, I remove the Y component, and I fix bug Z. To me, this should be three commits: X, Y, and Z, one for each of the changes.
But to get to the final point, I probably haven't done that in only three steps. What I've probably done is I've tried out change W, but that didn't help at all so I abandoned it, then I started doing Y, realised that I needed to do X first for Y to make sense, so I switched and did X, then I finished Y, then I could do Z. Then I realised that while doing X I'd forgotten some stuff so I finished that off, then I realised that the tests weren't passing because part of Y wasn't finished. Then I pushed everything and the reviewer pointed out that while fixing Z, I'd left some code commented out and I needed to remove it properly.
Long-term, which of these sets of changes would be most useful? Surely the first one: it shows my aim while making changes, it is clearly bisectable, and it is divided into clean units of work without overlap or having those units intermingled. As a future developer, I can run `git blame` or equivalent and clearly see why each line of code was changed, and for what reason.
Whereas with the latter case, bisecting the codebase will stumble on all the intermediate situations where a test failed or the code didn't compile or whatever, because bad states during the development process are now part of the permanent history. And it'll produce spurious results when I try to annotate a file: the last time this file was changed was because I temporarily commented out this line and then immediately commented it back in again, how do I see only the changes that made a meaningful impact to this line?
In my experience, recording these sorts of "fixup" changes permanently in the history has never been useful. Having clear, precise commits that each do one thing: definitely, yes, this is a fantastic tool. But being able to go back in time with such granularity as to see when you broke a test and then fixed it in review? Or when you started out doing one change and then did something else instead in a different order? I have never found that level of detail useful, and it is often makes things harder when I'm trying to focus on the significant commits and changes and just want to filter all of those out.