[PATCH RFC] update: add an option to allow to merge local changes when crossing branches
gilles.moris at free.fr
Thu Feb 28 09:24:32 CST 2013
On Wednesday 27 February 2013 11:24:24 pm Martin Geisler wrote:
> 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
> >>> below.
> >> 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
> >> commits.
> > 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 :)
Yes you are right, all the patch does is pa = p1, where pa provides the
ancestor to the merge engine and p1 is the parent of the working copy. It
just extends what the linear case already does.
I think one of the tricky point is that there is currently no easy way to
revert from a working copy merge, even in the linear case. Either we document
your trick, or we try to provide a more intuitive way. I am going to look how
to tackle that one.
Once we have that, we may rediscuss whether we can allow merge of the working
copy by default when crossing branches.
More information about the Mercurial-devel