Re: [RFC v2] Rebasing merges: a jorney to the ultimate solution (Road Clear)

[Igor Djordjevic <igor.d.djordjevic@gmail.com>]

Hi Dscho,

On 11/03/2018 16:47, Johannes Schindelin wrote:
> 
> > > > Phillip's method is essentially merging the new tips into the original
> > > > merge, pretending that the new tips were not rebased but merged into
> > > > upstream.
> > >
> > > [...]
> > >
> > > Here`s a starting point, two commits A and B, merged into M:
> > >
> > > (3) ---A
> > >         \
> > >          M
> > >         /
> > >     ---B
> > >
> > >
> > > According the "patch theory"[1] (which might not be too popular 
> > > around here, but should serve the purpose for what I`m trying to 
> > > explain), each merge commit can be "transformed" to two non-merge 
> > > commits, one on top of each of the merge parents, where new commit 
> > > brings its original merge parent commit tree to the state of the 
> > > merge commit tree:
> > >
> > > (4) ---A---U1
> > >
> > >
> > >
> > >     ---B---U2
> > >
> > >
> > > Now, we have two new commits, U1 and U2, each having the same tree as 
> > > previous merge commit M, but representing changes in regards to 
> > > specific parents - and this is essentially what Sergey`s original 
> > > approach was using (whether he knew it, or not).
> > >
> > > When it comes to rebasing, it`s pretty simple, too. As this:
> > >
> > > (5) ---X1---o---o---o---o---o---X2 (master)
> > >        |\
> > >        | A1---A2---A3
> > >        |             \
> > >        |              M
> > >        |             /
> > >        \-B1---B2---B3
> > >
> > > ... actually equals this:
> > >
> > > (6) ---X1---o---o---o---o---o---X2 (master)
> > >        |\
> > >        | A1---A2---A3---U1
> > >        |
> > >        |
> > >        |
> > >        \-B1---B2---B3---U2
> > >
> > > ... where trees of M, U1 and U2 are same, and we can use the regular 
> > > rebase semantics and rebase it to this:
> > >
> > > (7) ---X1---o---o---o---o---o---X2 (master)
> > >                                 |\
> > >                                 | A1'--A2'--A3'--U1'
> > >                                 |
> > >                                 |
> > >                                 |
> > >                                 \-B1'--B2'--B3'--U2'
> > >
> > > ... which is essentially this again:
> > >
> > > (8) ---X1---o---o---o---o---o---X2 (master)
> > >                                 |\
> > >                                 | A1'--A2'--A3'
> > >                                 |            \
> > >                                 |             M'
> > >                                 |            /
> > >                                 \-B1'--B2'--B3'
> > >
> >
> > Having explained all this, I realized this is the same "essentially 
> > merging the new tips into the original pretending that the new tips 
> > were not rebased but merged into upstream" as Phillip`s one, just 
> > that we have additional temporary commits U1 and U2 (as per mentioned 
> > "patch theory") :)
> 
> But if the old tips had been merged into upstream (resulting in the new
> tips), then the merge bases would be *the old tips*.

Exactly, and that is what part you`ve cut out of the quote was 
showing :) By Phillip`s implementation, we would start with *old tips* 
as merge bases, indeed (old tips being U1 and U2 in this case), where 
it further gets transformed as previously written:

> 	git merge-recursive U1 -- M U1'
> 	tree="$(git write-tree)"
> 	git merge-recursive U2 -- $tree U2'
> 	tree="$(git write-tree)"
> 
> ..., where we know U1 = U2 = M (in regards to trees), so this is the 
> same as:
> 
> 	git merge-recursive M -- M U1'
> 	tree="$(git write-tree)"
> 	git merge-recursive M -- $tree U2'
> 	tree="$(git write-tree)"

Here, `git merge-recursive M -- M U1'` simply equals to U1' tree 
(being a fast-forward merge), so we can write the two merges above as
a single merge, too:

> 	git merge-recursive M -- U1' U2'
> 	tree="$(git write-tree)"
> 
> ... which is exactly what Sergey`s (updated) approach suggests, 
> merging U1' and U2' with M as merge-base (and shown inside that 
> sample implementation script I provided[1]) :)

So from *old tips* being the rebased merge base (Phillip), we got to 
*old merge commit* being the rebased merge base (Sergey), or vice 
versa. Does this shed a bit more light on it now? Or you wanted to 
point out something else in the first place...?

> I am still not sure for what scenarios Phillip's strategy is the same as
> Sergey's (updated) one, as the former strategy can do completely without
> temporary commits [...]

I think the root of misunderstanding might be coming from the fact 
that Sergey was mainly describing a general concept (without a 
strictly defined implementation strategy, not being restricted to a 
specific one), where Phillip came up with a solution that eventually 
seems to use the same concept (as those transformations above should 
show), but simplifying it further inside a concrete implementation.

By saying that Phillip "simplified it", even though transformations 
shown above might show different, I mean he managed to further 
decompose what Sergey was aiming for, abstracting temporary commits U1 
and U2 out of the equation, thus making them optional, but not 
required.

So, if easier to implement and reason about, I think what Phillip 
described is a way to go to produce the rebased merged commit - but 
in case we want to have that "clean rebased merge" check that U1' == 
U2' comparison does provide, as they should really be the same (tree 
wise) in simple (and the most used?) merge rebasing, we can do that 
after the fact, even.

Might be this check could be the most useful in non-interactive 
rebases, where rebased merge parents` trees could be expected to stay 
"balanced" more often (U1' == U2'), without interactive fiddling to 
"disbalance" them. I don`t know, just thinking out loud.

> [...] and cannot introduce ambiguities when rebasing the
> changes introduced by M (i.e. the "amendmendts" we talked about).

Hmm, not following here, which ambiguities are we talking about?

Thanks, Buga