Hacker News Reader

Comment by vertex-four | Hacker News Reader

Shouldn't we then have a tool which separates out "published, shared" commits from WIP commits, if they're different "types"?

View on HN

Yeah, Mercurial phases handles this:

http://mercurial.selenic.com/wiki/Phases

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.

> 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

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.

What do you mean by squashing the commits? Why would it matter if you do a pull request after committing a lot?

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.

Reply on news.ycombinator.com