From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Igor Djordjevic <igor.d.djordjevic@gmail.com>
Cc: phillip.wood@dunelm.org.uk, Sergey Organov <sorganov@gmail.com>,
Git mailing list <git@vger.kernel.org>,
Jacob Keller <jacob.keller@gmail.com>,
Johannes Sixt <j6t@kdbg.org>, Junio C Hamano <gitster@pobox.com>
Subject: Re: [RFC] Rebasing merges: a jorney to the ultimate solution (Road Clear)
Date: Mon, 5 Mar 2018 18:29:56 +0100 (STD)
Message-ID: <nycvar.QRO.7.76.6.1803051812330.20700@ZVAVAG-6OXH6DA.rhebcr.pbec.zvpebfbsg.pbz> (raw)
In-Reply-To: <872944c4-ca97-9f55-a424-86d1e3299a22@gmail.com>
Hi Buga,
On Sat, 3 Mar 2018, Igor Djordjevic wrote:
> By the way, is there documentation for `git merge-recursive`
> anywhere, besides the code itself...? :$
I am not aware of any. The commit message adding the command is not very
illuminating (https://github.com/git-for-windows/git/commit/720d150c4):
Add a new merge strategy by Fredrik Kuivinen.
I really wanted to try this out, instead of asking for an adjustment
to the 'git merge' driver and waiting. For now the new strategy is
called 'fredrik' and not in the list of default strategies to be tried.
The script wants Python 2.4 so this commit also adjusts Debian and RPM
build procecure files.
Digging through https://public-inbox.org/git/ during that time frame comes
up with this hit, though:
https://public-inbox.org/git/20050907164734.GA20198@c165.ib.student.liu.se/
which is still not a good documentation of the algorithm. You can probably
dig further yourself, but I think I can describe it very quickly here:
To merge two commits recursively, you first have to find their "merge
bases". If there was an obvious branch point, then that is the merge base.
But when you start a branch off of master, then work a bit, then merge
master, you already have two merge bases.
The trick about the recursive merge is to reduce the number of merge bases
iteratively to one. It does that by taking two merge bases, and performing
a recursive merge on them, which generates a "virtual" commit, the
condensed merge base. That one is then merged recursively with the next
merge base, until there is only one left.
A recursive merge of two commits with exactly one merge base is simply a
three-way merge.
I vaguely remember that there was something funny about the order in which
order you want to process the merge bases: if you did it in one
(chronological) direction, it worked beautifully, in the other direction
it would generate tons of merge conflicts or something like that.
Ciao,
Johannes