Re: The merge from hell...

From: Junio C Hamano <junkio@cox.net>
Date: Feb 3, 2006, 06:28 UTC
Message-ID: <7vbqxpj6qs.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.64.0602022139190.3462@g5.osdl.org>

Linus Torvalds <torvalds@osdl.org> writes:

> The 12-way merge was a bit over the top, but it worked. I'd suggest not 
> beign quite _that_ aggressive in the future, though, but it's not a big 
> deal.

Heh, I was quietly planning to raise the limit, or lift it altogether ;-).

I find Len's explanation that those topics cooked independently and happened to mature at about the same time an excellent excuse to record this as an Octopus, and with that usage there is no inherent reason, other than making the diff completely unreadable, to limit the number of parents. But I tend to agree that the current 16 is a sane limit in practice.

That reminds me of another practical limit I've known but did nothing about for quite some time (you may not even remember doing that parser anymore). This does not work for Len's merge:

	$ git rev-parse --verify funmerge^10

You could do a 16-way merge but 12-way is already hitting usability limit, depending on what you would want to do with them. For example, you cannot easily decompose the topic branches out of that merge, like this:

	$ git checkout -b redo-3549 funmerge^2     ;# works
        $ git checkout -b redo-pnpacpi funmerge^12 ;# doesn't

> One thing I'd ask for: would it be possible to have more descriptive 
> branch names than just numbers? Even if you want to track it by bugzilla 
> entry number, how about calling it "bugzilla-12345" instead?

When kernel people (not just Len) talk about a "bugzilla ID", does that ID always come from the same namespace, or do some subsystems have their own bugzilla?