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@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. Ciao, Johannes
