If you're using Git or another version control that can do squash/rebase, what would be the advantage of having a separate concept of "temporary commits" or something?
In addition, git has a staging area (git add), which I use to stage intermediate steps of work.
It's a good idea to have only "clean" commits in your master branch (to allow for easy blame/bisect) but you can easily do feature branches that can remain "dirty" before squashing and merging to master.
> If you're using Git or another version control that can do squash/rebase, what would be the advantage of having a separate concept of "temporary commits" or something?
It'd be nice to be able to mark commits as "squashable" as I went along (without actually squashing them yet), rather than finishing my feature branch and then have to go back and remember which commits were the "good" ones.
As another poster pointed out, Mercurial phases are the answer to this. I don't know if very many mercurial users actually use them this way consciously or not. Most mercurial people that are deliberately and intensely into this workflow learned to use mercurial patch queues before phases existed (patch queues are basically the git staging area on steroids).
It's more of a workflow thing. When working on a difficult feature, or rather difficult ticket, that cannot reasonably split into 2, it makes sense to work on a separate feature branch. This branch is just for yourself and can be polluted with dirty commits. Once your done, your can git rebase the thing into one, beautiful commit.
If you're working in a feature branch I don't think it would be that much of a problem to be honest. Just be sure to squash the commits before writing the pull request later on.
You can squash or rebase history in Git, which basically means you compress all your changes into a single one. People use this to keep a clean history.
