66-way merge: “Christ, that's not an octopus, that's a Cthulhu merge” | Hacker News Reader

66-way merge: “Christ, that's not an octopus, that's a Cthulhu merge”

lkml.org

40 pointsjjuhl19 comments

> Yep, sorry, it's my fault that I overlooked Medusa there. I usually check with gitk, but at this time, I checked the results only via --no-merges option for concentrating on the real changes.

> Now I looked at it, and I was turned into sto..n...e...... Takashi [0]

[0] https://lkml.org/lkml/2014/1/23/80

Commit: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

I wasn't even aware that Git is capable of merging from more than N=2 parents (technically a three-way merge) ...

Is this a relatively new feature? And what is the use-case for N>2?

It's been there for a long time AFAIK... not sure what the use case is though. (I guess if they're all non-conflicting then it's chill?)

Perhaps the use-case is "consensus". I.e., when you have a 66-way merge and 50 of those say "x=0;" and 16 of those say "x=1;", then it can pick the one with the most consensus, i.e. "x=0;". Or something like that ...

EDIT: of course using a special flag, otherwise indeed it could lead to problems.

I'd wager it's just to make life a bit easier, not because of any technical advantages... i.e. so that they don't have to sign off on 66+ commits for a 66-commit merge.

What is the likelihood that the commits making up the different versions would be byte-for-byte identical, however?

They don't need to be identical. You could use the same kind of algorithms as bioinformaticians use to merge multiple different DNA sequences (which can be of different length).

https://en.wikipedia.org/wiki/Edit_distance

https://en.wikipedia.org/wiki/Consensus_sequence

If git did that automatically, without reporting a merge conflict, that would be a disaster. Suppose there were more Americans on team 1 of the Mars Climate Orbiter and more Europeans on team 2, so team 1 chose imperial units by consensus and team 2 chose metric units by consensus. That isn't going to give a stable system.

It allows a reduction of (useless) merge commits. Assume you have 8 different branches (without conflicts) that you need to merge. Then you can either have 8 merge commits (merged $number into master), or a single one (merged 1,2,3,4,5,6,7,8 into master).

If you have no conflicts, it makes the history much cleaner without losing relevant history.

The reason github's mascot is Octocat is because of octopus merges!

http://cameronmcefee.com/work/the-octocat/

Interesting, but kind of strange that the mascot is based on (I suppose) one of Git's least used/useful features.

There is a good explanation over here[0]. Also, HN-discussion for this article[1].

[0] https://www.destroyallsoftware.com/blog/2017/the-biggest-and... [1] https://news.ycombinator.com/item?id=13647927

Git merges aren't really merges in the sense that they store a delta produced by some kind of N-way merge algorithm. A git commit is essentially a full copy of a tree where the parents are stored as simple metadata attributes. The parent links are used by tools like "git log" to show how code evolved. But that evolution is calculated on the fly from the difference between trees.

In the data model of git, a 66-way merge is therefore nothing special. It's simply a tree with 66 parent links.

This just seems like a challenge for someone to come up with an even more extreme one.

Apparently tipbot has merged a commit with 243 parents before. [0] Getting much worse might require some truly pathological circumstances.

[0] https://lkml.org/lkml/2014/1/23/611

as discussed over here: https://news.ycombinator.com/item?id=17265151

(2014)

Reply on news.ycombinator.com