Hacker News Reader

Comment by exDM69 | Hacker News Reader

Why would this be advantageous?

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.

View on HN

> 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).

You can do that with autosquash https://coderwall.com/p/hh-4ea

Is there an equivalent with a looser match? Half the time I don't remember what my last commit message was.

No, but this explains a nice trick to use it without remembering the commit message http://technosorcery.net/blog/2012/08/05/updated-git-rebase-...

With that you can do:

    git fixup HEAD~2

Reply on news.ycombinator.com