[PATCH STABLE] graft: support grafting across renames (issue4028)
Yuya Nishihara
yuya at tcha.org
Wed Jul 27 11:05:03 EDT 2016
On Tue, 26 Jul 2016 12:39:50 -0500, Matt Mackall wrote:
> On Wed, 2016-07-27 at 00:07 +0900, Yuya Nishihara wrote:
> > On Mon, 25 Jul 2016 13:16:32 -0500, Gábor Stefanik wrote:
> > > # HG changeset patch
> > > # User Gábor Stefanik <gabor.stefanik at nng.com>
> > > # Date 1469470573 -7200
> > > # Mon Jul 25 20:16:13 2016 +0200
> > > # Branch stable
> > > # Node ID 395d3fa2ac89fad199c99cc137bf801502292325
> > > # Parent 9c2cc107547fd701a7604349632f2f590366f17c
> > > graft: support grafting across renames (issue4028)
> > >
> > > Graft performs a merge with a false common ancestor, which must be taken
> > > into
> > > account when tracking renames. Compute the real common ancestor in this
> > > case,
> > > and track renames between the real and false common ancestors in reverse.
> > I don't know the detail of the copy tracing, I can't tell if this strategy
> > is correct.
> >
> > Many tests fails with this patch.
>
> Yes, I'm afraid it's much trickier than this.
>
> Basically, the main copy tracing function for merges assumes all merges go
> forward in history because it was written before we had any form of rebasing or
> grafting.
>
> ancestor --> a - merge
> \ /
> --------> b
>
> But when we graft or rebase, we're doing a merge that looks like this:
>
> ancestor--<--a_parent-> a - b'
> \ /
> ------------------> b
>
> ..and twisting the graph to look like this:
>
> a_parent -------------> a - b'
> \ /
> --->-ancestor -----> b
>
> The stretch between a_parent and ancestor is backwards in the real history but
> gets flipped for our effective merge DAG. That means a rename of x to y in that
> span effectively becomes a rename from y to x for the purposes of our operation.
> But the spans from a_parent to a and from ancestor to b remain unflipped.
> Teaching mergecopies() how to do this amounts to a complete rewrite.
Ah, thanks. I think I finally understand the basic model.
> The situation with copies is even more confusing (search the list archives for a
> discussion of "ypoc"s).
For reference,
https://www.mercurial-scm.org/pipermail/mercurial-devel/2012-December/047183.html
More information about the Mercurial-devel
mailing list