First: are we talking past each others? You seem reasonable but some of the things doesn't make sense to me which often indicates a misunderstanding on one of the sides :-)
If not, here are some clarifications. (Maybe they'll help even if we are talking past each other.)
> Removing can't always be done later, because that requires rewriting the repository's history.
I knew this could come up which is why I included glossed over.
> Logical commits serve a real purpose: they make change review easier and can help bisect bugs later.
Nothing I wrote was meant to conflict with that. Quite on the contrary I specifically want more points to bisect against (yes, I'm one of those who actually uses bisect).
> If thought process is important, it should be captured in a structured way like a thoughtful commit message or README addition. Not some cobbled together mess of whatever commits someone made haphazardly.
Have you tried getting anything reasonable about the thought process behind a feature into a README, and then tried to get it to stick there?
On the other hand a bunchbof commits along the lines of:
- rough first sketch
- introduce tests.
Also includes modifications to xyz to simplify testing.
- performance optimizations
- more tests
- Introduce test for foo and fix it in bar and baz
This has a negative impact on performance but is hard to avoid.
Could you please elaborate on the value you find in commits from other people that are along the lines of "more tests" or "first sketch", as opposed to crafting a coherent single commit with a thoughtful commit message?
I'm honestly asking in good faith, as the commits you gave as an example are literal anathema to me, and I'd like to understand what value anyone can see in them.
The one I value is the "performance optimizations" and the last one.
Problem is if we let squash zealots have their way they are gone together with the rest.
Storage is cheap.
You'll never ever be bothered by those commits unless you are bisecting and at that point you are probably thankful of you can find a commit message along the lines of:
- performance optimizations
- workaround for weird problem foo problem in prod
as they will tell you a lot about how to approach it.
Edit:
Just having tests and modification because of tests added in their own commit and with a comment ("Also includes modifications to xyz to simplify testing." above) is useful.
I do look into commits on a weekly basis or more to figure out why stuff was moved / replaced.
Just yesterday I stopped a PR because a constant was changed in an unrelated commit as part of the larger PR.
Because commits are granular it was really easy to see that it wasn't intended.
Just make sure every step make sense. One or even two or three extra bisect steps is nothing in my kind of projects as long as you get a very specific change.
I guess on AAA game engines where compiles take half an hour it is more of a problem but in my case it takes 30 - 120 seconds depending on project.
(I do have uncompilable WIP steps, and those I am kind of ashamed for but those are so few and so far between that it doesn't matter.)
If not, here are some clarifications. (Maybe they'll help even if we are talking past each other.)
> Removing can't always be done later, because that requires rewriting the repository's history.
I knew this could come up which is why I included glossed over.
> Logical commits serve a real purpose: they make change review easier and can help bisect bugs later.
Nothing I wrote was meant to conflict with that. Quite on the contrary I specifically want more points to bisect against (yes, I'm one of those who actually uses bisect).
> If thought process is important, it should be captured in a structured way like a thoughtful commit message or README addition. Not some cobbled together mess of whatever commits someone made haphazardly.
Have you tried getting anything reasonable about the thought process behind a feature into a README, and then tried to get it to stick there?
On the other hand a bunchbof commits along the lines of:
- rough first sketch
- introduce tests.
Also includes modifications to xyz to simplify testing.
- performance optimizations
- more tests
- Introduce test for foo and fix it in bar and baz
This has a negative impact on performance but is hard to avoid.
etc