3 ms·

Mercurial Queues are like Git's index on steroids

• tzs 16y ago
  I thought the closest thing in Git to Mercurial queues was Git stashes.
  • stevelosh 16y ago
    Nope, that's probably the shelve extension: http://mercurial.selenic.com/wiki/ShelveExtension http://mercurial.selenic.com/wiki/ShelveExtension
• Vitaly 16y ago
  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 16y ago
    "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 http://mercurial.selenic.com/wiki/HisteditExtension