Comments on: On rebasing http://kbullock.ringworld.org/2009/04/24/on-rebasing/ god, tech, and other geekery Thu, 29 Jul 2010 15:16:02 -0500 http://wordpress.org/?v=2.9.2 hourly 1 By: Kevin http://kbullock.ringworld.org/2009/04/24/on-rebasing/comment-page-1/#comment-58 Kevin Fri, 24 Apr 2009 22:02:00 +0000 /2009/04/30/on-rebasing#comment-58 <p>I played with that a bit, but I'd rather not simplistically have a duplicate of <code>rebase</code> for Mercurial.</p> <p>What's the advantage of the <code>rebase</code> extension over the workflows I described above?</p> I played with that a bit, but I’d rather not simplistically have a duplicate of rebase for Mercurial.

What’s the advantage of the rebase extension over the workflows I described above?

]]> By: Anonymous http://kbullock.ringworld.org/2009/04/24/on-rebasing/comment-page-1/#comment-60 Anonymous Fri, 24 Apr 2009 22:02:00 +0000 /2009/04/30/on-rebasing#comment-60 <p>You wrote</p> <blockquote>What I do is as follows; for an alternate (probably better) strategy, see MqMerge on the Mercurial wiki.</blockquote> <p>The difference between the approaches is that your approach does not deal with conflicts in your patches and the newly pulled changesets. That is, when you run "hg qpop -a; hg pull -u; hg qpush -a;", the qpush command will fail when the patch can not apply cleanly as a result of a merge conflict. If there is a conflict, you will either get reject (.rej) files or you'll get the result of a fuzzy merge which requires checking before continuing. The approach on the Mercurial wiki using qsave solves this problem using Mercurial's merge ability so it can, for example, popup a graphical merge utility to merge each patch. It detects when a patch does not apply cleanly and only then launches the merge program.</p> You wrote

What I do is as follows; for an alternate (probably better) strategy, see MqMerge on the Mercurial wiki.

The difference between the approaches is that your approach does not deal with conflicts in your patches and the newly pulled changesets. That is, when you run "hg qpop -a; hg pull -u; hg qpush -a;", the qpush command will fail when the patch can not apply cleanly as a result of a merge conflict. If there is a conflict, you will either get reject (.rej) files or you’ll get the result of a fuzzy merge which requires checking before continuing. The approach on the Mercurial wiki using qsave solves this problem using Mercurial’s merge ability so it can, for example, popup a graphical merge utility to merge each patch. It detects when a patch does not apply cleanly and only then launches the merge program.

]]> By: pachi http://kbullock.ringworld.org/2009/04/24/on-rebasing/comment-page-1/#comment-57 pachi Fri, 24 Apr 2009 17:02:00 +0000 /2009/04/30/on-rebasing#comment-57 <p>I'd urge you to have a look to Mercurial's rebase extension. It's distributed with mercurial but, as any other history modifying feature, needs to be activated as an extension (just add [extensions]\nrebasee= to your config file...</p> I’d urge you to have a look to Mercurial’s rebase extension. It’s distributed with mercurial but, as any other history modifying feature, needs to be activated as an extension (just add [extensions]\nrebasee= to your config file…

]]> By: Arne Babenhauserheide http://kbullock.ringworld.org/2009/04/24/on-rebasing/comment-page-1/#comment-59 Arne Babenhauserheide Fri, 24 Apr 2009 17:02:00 +0000 /2009/04/30/on-rebasing#comment-59 <p>A main advantage is that the workflows with rebase might be what the people are used to.</p> A main advantage is that the workflows with rebase might be what the people are used to.

]]>