{"thread":{"id":"3224","subject":"RE: The merge from hell...","startedAt":"2006-02-03T04:20:54Z","lastAt":"2006-02-03T16:21:33Z","messageCount":5,"participants":["Brown, Len","Linus Torvalds","Junio C Hamano","Dave Jones"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"15505","messageId":"F7DC2337C7631D4386A2DF6E8FB22B3005EFE7FF@hdsmsx401.amr.corp.intel.com","threadId":"3224","inReplyTo":null,"subject":"RE: The merge from hell...","fromName":"Brown, Len","fromEmail":"len.brown@intel.com","sentAt":"2006-02-03T04:20:54Z","receivedAt":"2006-02-03T04:20:54Z","isPatch":false,"sender":{"key":"len.brown@intel.com","avatar":"https://gravatar.com/avatar/a091f34f66caadb51d85a8a496800c6ccae73737e2f45762373e6b8c55fa5dd6?d=mp&s=160"},"body":" \n>Thank Len. He may have done it as a way to avoid having extra merges, \n>since I complained about those last time ;)\n\nSeems I'm batting 1000 for entertainment value\nover my last two kernel patch pushes:-)\n\nThe previous one I took abuse for unwittingly cluttering\nhistory with \"extra\" merges.  The thread went on\nand on, but buried in there were some interesting\nobservations on work flow, and somebody\nasserted that the \"cleanest\" way to cherry pick\nthe topic branches onto the release branch was\nwith a multi-branch merge.\n\nAs git merge seemed to advertise support for it w/o\nme needing to learn a new command, I tried it out\nand it seemed to work fine -- including a nice colorful\ndiagram in gitk:-)\n\nI can do 16 next time, or 22, or none -- or you can have\ngit merge under the covers do this via iteration instead\nof all at once -- that's up to you guys.  My topic branches\ntend to be disjoint topics with little expected overlap;\nso grabbing a bunch of them when they're fully \"cooked\"\nin -mm and plunking them down in one merge is actually\nan example of history matching reality.\n\ncheers,\n-Len\n"},{"id":"15508","messageId":"Pine.LNX.4.64.0602022139190.3462@g5.osdl.org","threadId":"3224","inReplyTo":"F7DC2337C7631D4386A2DF6E8FB22B3005EFE7FF@hdsmsx401.amr.corp.intel.com","subject":"RE: The merge from hell...","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-02-03T05:45:57Z","receivedAt":"2006-02-03T05:45:57Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 2 Feb 2006, Brown, Len wrote:\n> \n> I can do 16 next time, or 22, or none\n\nActually, you can't do 22:\n\n\t/*\n\t * Having more than two parents is not strange at all, and this is\n\t * how multi-way merges are represented.\n\t */\n\t#define MAXPARENT (16)\n\n(commit-tree.c).\n\nNow, admittedly you should literally need no more than to change that \n#define and recompile, but at least by default, git-write-tree won't \naccept more than 16 parents.\n\nThe 12-way merge was a bit over the top, but it worked. I'd suggest not \nbeign quite _that_ aggressive in the future, though, but it's not a big \ndeal.\n\nOne thing I'd ask for: would it be possible to have more descriptive \nbranch names than just numbers? Even if you want to track it by bugzilla \nentry number, how about calling it \"bugzilla-12345\" instead? \n\nI can make the educated guess that it's the bugzilla.kernel.org tracking \nnumber, but still.. I think it would make the changelog more readable and \nunderstandable to outsiders.\n\n\t\tLinus\n"},{"id":"15512","messageId":"7vbqxpj6qs.fsf@assigned-by-dhcp.cox.net","threadId":"3224","inReplyTo":"Pine.LNX.4.64.0602022139190.3462@g5.osdl.org","subject":"Re: The merge from hell...","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-03T06:28:43Z","receivedAt":"2006-02-03T06:28:43Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds <torvalds@osdl.org> writes:\n\n> The 12-way merge was a bit over the top, but it worked. I'd suggest not \n> beign quite _that_ aggressive in the future, though, but it's not a big \n> deal.\n\nHeh, I was quietly planning to raise the limit, or lift it\naltogether ;-).\n\nI find Len's explanation that those topics cooked independently\nand happened to mature at about the same time an excellent\nexcuse to record this as an Octopus, and with that usage there\nis no inherent reason, other than making the diff completely\nunreadable, to limit the number of parents.  But I tend to agree\nthat the current 16 is a sane limit in practice.\n\nThat reminds me of another practical limit I've known but did\nnothing about for quite some time (you may not even remember\ndoing that parser anymore).  This does not work for Len's merge:\n\n\t$ git rev-parse --verify funmerge^10\n\nYou could do a 16-way merge but 12-way is already hitting\nusability limit, depending on what you would want to do with\nthem.  For example, you cannot easily decompose the topic\nbranches out of that merge, like this:\n\n\t$ git checkout -b redo-3549 funmerge^2     ;# works\n        $ git checkout -b redo-pnpacpi funmerge^12 ;# doesn't\n\n> One thing I'd ask for: would it be possible to have more descriptive \n> branch names than just numbers? Even if you want to track it by bugzilla \n> entry number, how about calling it \"bugzilla-12345\" instead? \n\nWhen kernel people (not just Len) talk about a \"bugzilla ID\",\ndoes that ID always come from the same namespace, or do some\nsubsystems have their own bugzilla?\n"},{"id":"15515","messageId":"7virrwj31n.fsf_-_@assigned-by-dhcp.cox.net","threadId":"3224","inReplyTo":"7vbqxpj6qs.fsf@assigned-by-dhcp.cox.net","subject":"[PATCH] get_sha1_1: allow octopus^12 to be properly parsed.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-03T07:48:36Z","receivedAt":"2006-02-03T07:48:36Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"We probably thought anybody who does more than 9 parents in an\nOctopus is insane when this was initially done, but there is no\ninherent reason to limit the number of independent topic\nbranches that happen to mature at the same time.\n\nOur commit-tree allows up to 16 already, so at least we should\nprepare to handle what we can produce, if only to be consistent.\n\nSigned-off-by: Junio C Hamano <junkio@cox.net>\n\n---\n\n Junio C Hamano <junkio@cox.net> writes:\n\n > That reminds me of another practical limit I've known but did\n > nothing about for quite some time (you may not even remember\n > doing that parser anymore).  This does not work for Len's merge:\n >\n > \t$ git rev-parse --verify funmerge^10\n >\n > You could do a 16-way merge but 12-way is already hitting\n > usability limit, depending on what you would want to do with\n > them.  For example, you cannot easily decompose the topic\n > branches out of that merge, like this:\n >\n > \t$ git checkout -b redo-3549 funmerge^2     ;# works\n >       $ git checkout -b redo-pnpacpi funmerge^12 ;# doesn't\n\n sha1_name.c |   39 ++++++++++++++++-----------------------\n 1 files changed, 16 insertions(+), 23 deletions(-)\n\n6c7e009d38da459545bd2eed63e7624f81cea90f\ndiff --git a/sha1_name.c b/sha1_name.c\nindex ba0747c..fa85d8a 100644\n--- a/sha1_name.c\n+++ b/sha1_name.c\n@@ -388,43 +388,36 @@ static int peel_onion(const char *name, \n \n static int get_sha1_1(const char *name, int len, unsigned char *sha1)\n {\n-\tint parent, ret;\n+\tint ret, has_suffix;\n \tconst char *cp;\n \n-\t/* foo^[0-9] or foo^ (== foo^1); we do not do more than 9 parents. */\n-\tif (len > 2 && name[len-2] == '^' &&\n-\t    name[len-1] >= '0' && name[len-1] <= '9') {\n-\t\tparent = name[len-1] - '0';\n-\t\tlen -= 2;\n-\t}\n-\telse if (len > 1 && name[len-1] == '^') {\n-\t\tparent = 1;\n-\t\tlen--;\n-\t} else\n-\t\tparent = -1;\n-\n-\tif (parent >= 0)\n-\t\treturn get_parent(name, len, sha1, parent);\n-\n \t/* \"name~3\" is \"name^^^\",\n-\t * \"name~12\" is \"name^^^^^^^^^^^^\", and\n \t * \"name~\" and \"name~0\" are name -- not \"name^0\"!\n+\t * \"name^\" is not \"name^0\"; it is \"name^1\".\n \t */\n-\tparent = 0;\n+\thas_suffix = 0;\n \tfor (cp = name + len - 1; name <= cp; cp--) {\n \t\tint ch = *cp;\n \t\tif ('0' <= ch && ch <= '9')\n \t\t\tcontinue;\n-\t\tif (ch != '~')\n-\t\t\tparent = -1;\n+\t\tif (ch == '~' || ch == '^')\n+\t\t\thas_suffix = ch;\n \t\tbreak;\n \t}\n-\tif (!parent && *cp == '~') {\n+\n+\tif (has_suffix) {\n+\t\tint num = 0;\n \t\tint len1 = cp - name;\n \t\tcp++;\n \t\twhile (cp < name + len)\n-\t\t\tparent = parent * 10 + *cp++ - '0';\n-\t\treturn get_nth_ancestor(name, len1, sha1, parent);\n+\t\t\tnum = num * 10 + *cp++ - '0';\n+\t\tif (has_suffix == '^') {\n+\t\t\tif (!num && len1 == len - 1)\n+\t\t\t\tnum = 1;\n+\t\t\treturn get_parent(name, len1, sha1, num);\n+\t\t}\n+\t\t/* else if (has_suffix == '~') -- goes without saying */\n+\t\treturn get_nth_ancestor(name, len1, sha1, num);\n \t}\n \n \tret = peel_onion(name, len, sha1);\n-- \n1.1.6.gb1a9\n"},{"id":"15521","messageId":"20060203162133.GF24201@redhat.com","threadId":"3224","inReplyTo":"7vbqxpj6qs.fsf@assigned-by-dhcp.cox.net","subject":"Re: The merge from hell...","fromName":"Dave Jones","fromEmail":"davej@redhat.com","sentAt":"2006-02-03T16:21:33Z","receivedAt":"2006-02-03T16:21:33Z","isPatch":false,"sender":{"key":"davej@redhat.com","avatar":null},"body":"On Thu, Feb 02, 2006 at 10:28:43PM -0800, Junio C Hamano wrote:\n\n > > One thing I'd ask for: would it be possible to have more descriptive \n > > branch names than just numbers? Even if you want to track it by bugzilla \n > > entry number, how about calling it \"bugzilla-12345\" instead? \n > \n > When kernel people (not just Len) talk about a \"bugzilla ID\",\n > does that ID always come from the same namespace, or do some\n > subsystems have their own bugzilla?\n\nNot only do some subsystems have their own bugtracker (ALSA for eg),\nbut referring to 'bugzilla' alone is meaningless, as it could\nmean bugme.osdl.org, bugzilla.redhat.com, bugzilla.novell.com,\nbugzilla.ubuntu.com etc etc, all of which are a prime source of\njuicy kernel bugs.\n\n\t\tDave\n"}]}