// Re-sending because of bounce On Sun, Feb 4, 2018 at 12:54 AM, Johannes Sixt <j6t@xxxxxxxx> wrote: > Am 03.02.2018 um 22:34 schrieb Elijah Newren: >> If anyone can find an >> example of a real world open source repository (linux, webkit, git, >> etc.) with a merge where n is greater than about 10, I'll be >> surprised. > > git rev-list --parents --merges master | > grep " .* .* .* .* .* .* .* .* .* .* " > > returns quite a few hits in the Linux repository. Most notable is > fa623d1b0222adbe8f822e53c08003b9679a410c; spoiler: it has 30 parents. > > -- Hannes Sorry, I didn't make it very clear what n represented. This is in the context of detecting directory renames, and in this discussion n represents the number of distinct directories that files were renamed into from a single original directory on a given side of the merge. So your example of number of parents of a commit isn't directly relevant to this case (also, even along your tangent, merge-recursive is only invoked when the number of parents is precisely two). However, I find your nugget rather interesting, even if unrelated. I had known of merges with more than 10 parents, but somehow was unaware that the limit of 16 parents had been lifted. And digging through the history, it was apparently removed quite a while ago. I love the commit message that lifted the limit too: "There is no really good reason to have a merge with more than 16 parents, but we have a history of giving our users rope." :-)
