[PATCH 1 of 1] rebase: hard-code 'hg pull --rebase' to use internal:fail merge tool

Sune Foldager cryo at cyanite.org
Thu May 26 07:55:41 CDT 2011


On 2011-05-26 13:58, Adrian Buehlmann wrote:
># HG changeset patch
># User Adrian Buehlmann <adrian at cadifra.com>
># Date 1306235416 -7200
># Node ID c365abdd8ec568b5aeaa658a7765c5969c005801
># Parent  0969d91fad5cad68bcf60f85e2e3286acd11ab52
>rebase: hard-code 'hg pull --rebase' to use internal:fail merge tool
>
>If there were changes that modified the same files in both the local and the
>pulled line of development, the rebase part of 'pull --rebase' will then
>be aborted (example):
>
>  $ hg pull --rebase
>  pulling from http://bitbucket.org/mirror/mercurial-crew
>  searching for changes
>  adding changesets
>  adding manifests
>  adding file changes
>  added 72 changesets with 123 changes to 50 files (+1 heads)
>  abort: unresolved conflicts (see hg resolve, then hg rebase --continue)
>
>instead of throwing a merge tool invocation at the user (which is too
>daunting for the class of users that are the typical fans of pull --rebase).

Does this actually work, though, if you are rebasing multiple local changesets?
Which part of the rebase does it abort? Normally, rebasing multiple changesets
would involve multiple merges as well.

>This leaves a uncommitted merge with unresolved conflicts (example continued):
>
>  $ hg resolve -l
>  U mercurial/revlog.py
>
>  $ hg -q parents
>  14393:bb5cbc16349e
>  14321:b7a77cf76ec7
>
>The user can then (manually or with a tool) edit the files to resolve the
>conflicts and mark the resolved files as resolved

Right.. but that's kinda a third workflow on top of rebase and merge isn't it?
I mean, at Edlund, no one knows about resolve. People either use rebase or
merge and resolve all conflicts in kdiff3. Ok, SOME people know, but many
don't. Not sure this makes it easier.


More information about the Mercurial-devel mailing list