Hi Buga, On Wed, 7 Mar 2018, Igor Djordjevic wrote: > On 05/03/2018 18:29, Johannes Schindelin 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@xxxxxxxxxxxxxxxxxxxxxx/ > > > > 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. > > Thanks, this is very informative (together with the linked discussion). > > Not remembering seeing this before, I wasn`t really sure if this was > some undocumented core Git (plumbing?) utility (used withing Git > itself, too), or just a leftover (yet still useful) sample tool. You raise a good point. The "recursive merge" is not really documented properly. Maybe you can enhance my vague description and provide a patch for Documentation/technical/? Thanks, Dscho
