# RE: The merge from hell... 5 messages from 2006-02-03 to 2006-02-03. Participants: Brown, Len, Linus Torvalds, Junio C Hamano, Dave Jones. Thread: https://gitlist.dev/t/3224 ## Brown, Len, 2006-02-03 04:20 Subject: RE: The merge from hell... Message-ID: URL: https://gitlist.dev/e/F7DC2337C7631D4386A2DF6E8FB22B3005EFE7FF%40hdsmsx401.amr.corp.intel.com ``` >Thank Len. He may have done it as a way to avoid having extra merges, >since I complained about those last time ;) Seems I'm batting 1000 for entertainment value over my last two kernel patch pushes:-) The previous one I took abuse for unwittingly cluttering history with "extra" merges. The thread went on and on, but buried in there were some interesting observations on work flow, and somebody asserted that the "cleanest" way to cherry pick the topic branches onto the release branch was with a multi-branch merge. As git merge seemed to advertise support for it w/o me needing to learn a new command, I tried it out and it seemed to work fine -- including a nice colorful diagram in gitk:-) I can do 16 next time, or 22, or none -- or you can have git merge under the covers do this via iteration instead of all at once -- that's up to you guys. My topic branches tend to be disjoint topics with little expected overlap; so grabbing a bunch of them when they're fully "cooked" in -mm and plunking them down in one merge is actually an example of history matching reality. cheers, -Len ``` ## Linus Torvalds, 2006-02-03 05:45 Subject: RE: The merge from hell... Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.64.0602022139190.3462%40g5.osdl.org In-Reply-To: ``` On Thu, 2 Feb 2006, Brown, Len wrote: > > I can do 16 next time, or 22, or none Actually, you can't do 22: /* * Having more than two parents is not strange at all, and this is * how multi-way merges are represented. */ #define MAXPARENT (16) (commit-tree.c). Now, admittedly you should literally need no more than to change that #define and recompile, but at least by default, git-write-tree won't accept more than 16 parents. 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. 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? I can make the educated guess that it's the bugzilla.kernel.org tracking number, but still.. I think it would make the changelog more readable and understandable to outsiders. Linus ``` ## Junio C Hamano, 2006-02-03 06:28 Subject: Re: The merge from hell... Message-ID: <7vbqxpj6qs.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vbqxpj6qs.fsf%40assigned-by-dhcp.cox.net In-Reply-To: ``` Linus Torvalds 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? ``` ## Junio C Hamano, 2006-02-03 07:48 Subject: [PATCH] get_sha1_1: allow octopus^12 to be properly parsed. Message-ID: <7virrwj31n.fsf_-_@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7virrwj31n.fsf_-_%40assigned-by-dhcp.cox.net In-Reply-To: <7vbqxpj6qs.fsf@assigned-by-dhcp.cox.net> ``` We probably thought anybody who does more than 9 parents in an Octopus is insane when this was initially done, but there is no inherent reason to limit the number of independent topic branches that happen to mature at the same time. Our commit-tree allows up to 16 already, so at least we should prepare to handle what we can produce, if only to be consistent. Signed-off-by: Junio C Hamano --- Junio C Hamano writes: > 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 sha1_name.c | 39 ++++++++++++++++----------------------- 1 files changed, 16 insertions(+), 23 deletions(-) 6c7e009d38da459545bd2eed63e7624f81cea90f diff --git a/sha1_name.c b/sha1_name.c index ba0747c..fa85d8a 100644 --- a/sha1_name.c +++ b/sha1_name.c @@ -388,43 +388,36 @@ static int peel_onion(const char *name, static int get_sha1_1(const char *name, int len, unsigned char *sha1) { - int parent, ret; + int ret, has_suffix; const char *cp; - /* foo^[0-9] or foo^ (== foo^1); we do not do more than 9 parents. */ - if (len > 2 && name[len-2] == '^' && - name[len-1] >= '0' && name[len-1] <= '9') { - parent = name[len-1] - '0'; - len -= 2; - } - else if (len > 1 && name[len-1] == '^') { - parent = 1; - len--; - } else - parent = -1; - - if (parent >= 0) - return get_parent(name, len, sha1, parent); - /* "name~3" is "name^^^", - * "name~12" is "name^^^^^^^^^^^^", and * "name~" and "name~0" are name -- not "name^0"! + * "name^" is not "name^0"; it is "name^1". */ - parent = 0; + has_suffix = 0; for (cp = name + len - 1; name <= cp; cp--) { int ch = *cp; if ('0' <= ch && ch <= '9') continue; - if (ch != '~') - parent = -1; + if (ch == '~' || ch == '^') + has_suffix = ch; break; } - if (!parent && *cp == '~') { + + if (has_suffix) { + int num = 0; int len1 = cp - name; cp++; while (cp < name + len) - parent = parent * 10 + *cp++ - '0'; - return get_nth_ancestor(name, len1, sha1, parent); + num = num * 10 + *cp++ - '0'; + if (has_suffix == '^') { + if (!num && len1 == len - 1) + num = 1; + return get_parent(name, len1, sha1, num); + } + /* else if (has_suffix == '~') -- goes without saying */ + return get_nth_ancestor(name, len1, sha1, num); } ret = peel_onion(name, len, sha1); -- 1.1.6.gb1a9 ``` ## Dave Jones, 2006-02-03 16:21 Subject: Re: The merge from hell... Message-ID: <20060203162133.GF24201@redhat.com> URL: https://gitlist.dev/e/20060203162133.GF24201%40redhat.com In-Reply-To: <7vbqxpj6qs.fsf@assigned-by-dhcp.cox.net> ``` On Thu, Feb 02, 2006 at 10:28:43PM -0800, Junio C Hamano wrote: > > 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? Not only do some subsystems have their own bugtracker (ALSA for eg), but referring to 'bugzilla' alone is meaningless, as it could mean bugme.osdl.org, bugzilla.redhat.com, bugzilla.novell.com, bugzilla.ubuntu.com etc etc, all of which are a prime source of juicy kernel bugs. Dave ```