I second the "you're doing it wrong" note. The use of a tool that permits easy squashing and rebasing opens up new ways of doing development where you can commit and checkpoint at any moment, cheaply. So e.g. when you inevitably break something, you can bisect to where it happened, or when you find you've added a mismatched assumption you can see where the thought process went wrong.
You don't need to have things tidy, you know you can recover anything you do. So likewise when you're "done" you can squash and split them into changes that make more sense logically before pushing to some shared tree that someone else is going to have to reason about.
People who develop without tools like this tend to do it in a big flat directory and think about "commits" as something done every day or so. Once you get beyond that style, it feels really clumsy.
I think that preferences along these lines are inherently subjective, and some people may well really be better served by the more traditional workflow where every commit is something you commit to. I just wish this wasn't presented as the one and only right way to do things, to the point where software actively resists any other.
Isn't that backwards though? Git supports "rare commits that you commit to" just fine. It's Fossil that refuses to support the "commit rapidly and frequently on a whim and fix up a submission later" idiom.
> So likewise when you're "done" you can squash and split them into changes that make more sense logically before pushing to some shared tree that someone else is going to have to reason about.
Which keeps context which is my point.
The other case that I see is squashing it all into one that simply says 'Implemented feature Y' which doesn't provide any context into why something was changed.
You don't need to have things tidy, you know you can recover anything you do. So likewise when you're "done" you can squash and split them into changes that make more sense logically before pushing to some shared tree that someone else is going to have to reason about.
People who develop without tools like this tend to do it in a big flat directory and think about "commits" as something done every day or so. Once you get beyond that style, it feels really clumsy.