

Mercurial Queues are like Git's index on steroids - stevelosh
http://stevelosh.com/blog/2010/08/a-git-users-guide-to-mercurial-queues/

======
Vitaly
Actually its the other way around. Git branches with rebase and amend for
commits are like mercurial patch queues on steroids.

At Astrails we used mercurial for a couple of years with quite an elaborate
workflow involving _shared_ patch queues which were in their own mercurial
repository.

Once we switched to git I tried for a while to force similar workflow on git.
I investigated stgit, quilt etc to try to use patch queues with it. Nothing
quite worked so we kept just using the regular git with topic branches and
once I learned all the 'magic' git stuff like "commit --amend" and "rebase -i"
I realized I no longer needed patch queues. Actually the workflow become much
more streamlined and easy to follow.

~~~
stevelosh
"git rebase --interactive" can certainly be used instead of patch queues if
you're careful not to mess with published changesets. Mercurial has the
histedit extension[1] which does the same thing.

The one thing rebase -i and histedit can't really duplicate is _versioned_
patch queues. If you want to keep track of changes to patches over time then
rewriting history won't help you.

Perhaps you have a big feature with a bunch of moving parts that you want to
refine as you get feedback/code review. With versioned queues your colleagues
can see what parts of your patches changed since the last time they reviewed
them, instead of looking at the entire set of patches as a whole.

[1]: <http://mercurial.selenic.com/wiki/HisteditExtension>

------
tzs
I thought the closest thing in Git to Mercurial queues was Git stashes.

~~~
stevelosh
Nope, that's probably the shelve extension:
<http://mercurial.selenic.com/wiki/ShelveExtension>

