[PATCH RFC] update: add an option to allow to merge local changes when crossing branches
martin at geisler.net
Wed Feb 27 16:24:24 CST 2013
Kevin Bullock <kbullock+mercurial at ringworld.org> writes:
> On 23 Feb 2013, at 5:24 AM, Martin Geisler wrote:
>> Kevin Bullock <kbullock+mercurial at ringworld.org> writes:
>>> On 22 Feb 2013, at 2:35 PM, Martin Geisler wrote:
>>>> I don't know why you say the risk of conflicts is greater here than
>>>> with any other update/merge?
>>> Simply because you're merging a larger set of changes, as you get to
>> As you say, a merge because of a dirty working copy will use
>> * working copy parent (base)
>> * dirty working copy (local)
>> * update target (other)
>> That ought to be an easy merge regardless of the update target since
>> the difference between base and local is "small".
>> I say "small" because I expect the diff present in the dirty working
>> copy to be one commit. That is much smaller than most branch merges
>> where the distance from local/other to base is 10, 100 or more
> I was assuming that a cross-branch update would use:
> * common ancestor of target and WC (base)
> * dirty working copy (local)
> * update target on other branch (other)
> Is this not what the patch does?
I don't know this code well, but I think you're suggesting the wrong
ancestor: using the common ancestor of target and WC for a three-way
merge will make you merge the entire *branch* from "base" into "other".
You only want to merge the changes since the working copy parent, and
the working copy. For that you need the base to be the working copy
This is really a matter of committing the working copy, grafting the
commit to the target revision and uncommitting it again. I once made an
ASCII art graph of how I believe graft works:
I hope someone will correct me if I'm confused here :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 835 bytes
Desc: not available
More information about the Mercurial-devel