{"thread":{"id":"6971","subject":"[RFC/PATCH] commit-tree: bump MAX_PARENTS to 128","startedAt":"2007-02-26T12:15:57Z","lastAt":"2007-02-27T15:46:27Z","messageCount":12,"participants":["Jeff King","Shawn O. Pearce","Johannes Schindelin","Junio C Hamano","Andy Parkins","Jakub Narebski"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"35500","messageId":"20070226121557.GA18114@coredump.intra.peff.net","threadId":"6971","inReplyTo":null,"subject":"[RFC/PATCH] commit-tree: bump MAX_PARENTS to 128","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-02-26T12:15:57Z","receivedAt":"2007-02-26T12:15:57Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"This limit doesn't seem to come into effect anywhere else; it's simply\nan arbitrary limit to make memory allocation easier. It's used to\ndeclare a single static array of 20-byte hashes, so this increase wastes\nabout 2K.\n---\nThis limit is arbitrary; should it be ridiculously high (I think 128 is\nalready ridiculous, but we could go to 1024 and waste 20K). Or\nshould it simply allocate dynamically?\n\nI ran into this while trying to make an octopus with 25 heads. I have a\nset of 25 small repositories imported from CVS. They no longer see\nactive development, but I want to keep them around for historical\npurposes. Checking out 25 repos is a pain, so I wanted to put them all\nin one repo. However, I didn't just want the histories on separate\nbranches; I wanted everything checked out at once. So I did:\n\n rm -f .git/MERGE_HEAD\n for i in $repos; do\n git fetch ../$i $i\n git read-tree --prefix=$i/ $i\n git checkout -- $i\n git rev-parse $i >>.git/MERGE_HEAD\n done\n git commit\n\nWhich of course barfed on the giant octopus. Bumping up the limit\nallowed it to happen with no visible problems (the history browsing code\nworks fine). Yes, I obviously could have done a series of 25 pair-wise\nmerges (or even 2 16-way octopus merges), but I think this more closely\nrepresents what I'm trying to accomplish.\n\n builtin-commit-tree.c | 2 +-\n 1 files changed, 1 insertions(+), 1 deletions(-)\n\ndiff --git a/builtin-commit-tree.c b/builtin-commit-tree.c\nindex 2a818a0..48dbf1d 100644\n--- a/builtin-commit-tree.c\n+++ b/builtin-commit-tree.c\n@@ -60,7 +60,7 @@ static void check_valid(unsigned char *sha1, const char *expect)\n * Having more than two parents is not strange at all, and this is\n * how multi-way merges are represented.\n */\n-#define MAXPARENT (16)\n+#define MAXPARENT (128)\n static unsigned char parent_sha1[MAXPARENT][20];\n \n static const char commit_tree_usage[] = \"git-commit-tree [-p ]* < changelog\";\n-- \n1.5.0.1.793.gedfd5-dirty\n"},{"id":"35503","messageId":"20070226143142.GA1390@spearce.org","threadId":"6971","inReplyTo":"20070226121557.GA18114@coredump.intra.peff.net","subject":"Re: [RFC/PATCH] commit-tree: bump MAX_PARENTS to 128","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-02-26T14:31:42Z","receivedAt":"2007-02-26T14:31:42Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Jeff King wrote:\n> This limit doesn't seem to come into effect anywhere else; it's simply\n> an arbitrary limit to make memory allocation easier. It's used to\n> declare a single static array of 20-byte hashes, so this increase wastes\n> about 2K.\n\nI don't really see a problem with this, however:\n\nThe pack v4 code that Nico and I are working on was planning on\ntaking a very useful optimization for any commit with less than 64\nparents (or maybe 128, I'd have to go back to look at my notes).\nWe would fall back to a less optimal storage for these large\noctopus commits. Of course the fallback strategy (which is really\njust the current OBJ_COMMIT packing) is still more space efficient\nthan making multiple commits to express the octopus, so pushing\nthis limit up higher would save space better. Oh, and these types\nof octopus merges aren't very frequent either. ;-)\n\ngit-bisect can bisect these large octopuses, but it needs to search\nevery parent commit in the merge. It cannot perform a binary search\nthrough them. Getting massive octopuses makes it harder for the\nuser to bisect.\n\n\nI'm thinking maybe this should just change to a dynamic allocation\nand let the caller feed however many parents they want. Most people\ndon't make an octopus very often, and when they do they really mean\nto do it, such as the case you just described.\n\nUnless Dscho/Nico/Junio/Linus/etc. know of some other limitation\nlurking within Git. My recollection is that only git-commit-tree\nand git-gui knew about this 16 parent limit. And the latter only\nknows about the limit so that can prevent the user from doing an\noctopus merge that overflowed git-commit-tree's limit. Be nice if\ngit-gui has no limit. ;-)\n\n-- \nShawn.\n"},{"id":"35508","messageId":"Pine.LNX.4.63.0702261736570.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6971","inReplyTo":"20070226143142.GA1390@spearce.org","subject":"Re: [RFC/PATCH] commit-tree: bump MAX_PARENTS to 128","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-26T16:38:19Z","receivedAt":"2007-02-26T16:38:19Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 26 Feb 2007, Shawn O. Pearce wrote:\n\n> My recollection is that only git-commit-tree and git-gui knew about this \n> 16 parent limit.\n\nAFAIRC git-show-branch has a limit of 28 parents or so... But that is \npurely viewing porcelain...\n\nCiao,\nDscho\n"},{"id":"35579","messageId":"7vr6scj9qt.fsf@assigned-by-dhcp.cox.net","threadId":"6971","inReplyTo":"Pine.LNX.4.63.0702261736570.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [RFC/PATCH] commit-tree: bump MAX_PARENTS to 128","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-27T08:16:42Z","receivedAt":"2007-02-27T08:16:42Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> On Mon, 26 Feb 2007, Shawn O. Pearce wrote:\n>\n>> My recollection is that only git-commit-tree and git-gui knew about this \n>> 16 parent limit.\n>\n> AFAIRC git-show-branch has a limit of 28 parents or so...\n\nThat's limit of the number of _tips_ to traverse from, and I do\nnot think it has anything to do with maximum size of Octopus.\n\nBut as Shawn pointed out, Octopus makes bisect less (much less)\nefficient for the end users, I tend to think the current 16 is\nalready insanely large.\n"},{"id":"35580","messageId":"20070227081933.GA13021@coredump.intra.peff.net","threadId":"6971","inReplyTo":"7vr6scj9qt.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFC/PATCH] commit-tree: bump MAX_PARENTS to 128","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-02-27T08:19:33Z","receivedAt":"2007-02-27T08:19:33Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Feb 27, 2007 at 12:16:42AM -0800, Junio C Hamano wrote:\n\n> But as Shawn pointed out, Octopus makes bisect less (much less)\n> efficient for the end users, I tend to think the current 16 is\n> already insanely large.\n\nDid you look at my \"why I need a huge octopus\" description? Is there a\nbetter way to do it? Should I simply do a bunch of pair-wise merges?\nI'll almost certainly never bisect it, but the octopus \"looks right\" in\ngitk (though I have to admit, it's really not _that_ big a deal -- it's\nalmost more readable to look at pairwise merges anyway).\n\n-Peff\n"},{"id":"35585","messageId":"7virdnhpbt.fsf@assigned-by-dhcp.cox.net","threadId":"6971","inReplyTo":"20070227081933.GA13021@coredump.intra.peff.net","subject":"Re: [RFC/PATCH] commit-tree: bump MAX_PARENTS to 128","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-27T10:23:02Z","receivedAt":"2007-02-27T10:23:02Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Tue, Feb 27, 2007 at 12:16:42AM -0800, Junio C Hamano wrote:\n>\n>> But as Shawn pointed out, Octopus makes bisect less (much less)\n>> efficient for the end users, I tend to think the current 16 is\n>> already insanely large.\n>\n> Did you look at my \"why I need a huge octopus\" description? Is there a\n> better way to do it? Should I simply do a bunch of pair-wise merges?\n> I'll almost certainly never bisect it,...\n\nI hate having to compose this message because I know I will end\nup saying negative things without offering anything constructive.\n\nI do not think bundling commits from unrelated multiple projects\nin one commit (some people seem to have called this Hydra in the\npast) is a good practice, regardless of size.\n\nFor the sake of simplicity, suppose you are bundling two\nprojects A and B. The first such commit would have two parent\ncommits (the current tips of A and B). Next time you create\nanother Hydra, what will be its parents?\n\n * You do not care about the ancestry of Hydra itself, so it has\n two parents, then-current tips of A and B?\n\n * You do care about the ancestry of Hydra, so the first parent\n is the previous Hydra commit, the second parent is the\n then-current tip of A and the third parent is B?\n\nIf you do the former, then I do not think people can follow your\nprogress unless they have access to your reflog, so I am\nguessing that you are doing the latter.\n\nNow, do you have some files that are maintained by Hydra itself?\nDuct tape to hold these projects together, perhaps a Makefile to\nbuild the whole thing that does not belong to either A or B? I\nam also guessing the answer is yes, but you said you won't\nbisect it, so maybe this is not an issue. But let's pretend you\nhave something that you care about their evolution history in\nthe Hydra itself.\n\nThen, perhaps you would need to merge the ancestry of Hydras\nfrom time to time, if you have multiple concurrent development\ntracks of the bundled project. That means we cannot say the\nfirst parent is from Hydra itself and the rest are component\nprojects anymore (well, we cannot say that for the initial Hydra\ncommit itself already, but we could always special case the\n\"root\" commit). Perhaps we could say \"the last N are\ncomponents\", but then it is not clear what happens when you add\na new component.\n\nWhat bothers me is that in the usual commit all parents are\nequal, but in this case, you have different kinds of \"parent\"\ncommits and from the structure of the ancestry chain, you cannot\ntell which is what kind. Ancestry chain of some \"parent\"\ncommits represent how the bundling of components have evolved,\nwhile other \"parent\" commits are just pointers into different\nhistory.\n\nAlthough pointers to component project commits are represented\nas \"parent\" field in commit objects, I suspect that you wish\nthey were treated as if they were tree objects contained in the\ntoplevel commits more often than not for the purposes of many\ngit operations.\n\nIf we think about how bisect and merge _should_ work on such\nancestry chain of Hydras, my gut feeling is that the only way\nthat makes sense is to take only the first kind of ancestry (the\nevolution of the bundling of components) into account. Use them\nto determine the merge base to perform 3-way merge, count them\nto find the bisection point, etc.\n\nI am not saying that the problem you are trying to solve is a\nwrong problem. Rather, it is showing a gap between the\nstructure you are trying to express and the semantics of\nancestry chain git offers.\n\nCurrently there is nothing but commit objects that can have more\nthan one pointers to other commit objects, so if you wanted to,\nmaking an Octopus to fake it may be the only way to do so, but\nthe current ancestry chain semantics git offers is not set up to\ndistinguish the two different meanings of \"parent\" you are\ntrying to assign to commits, so it is very likely that many\nthings git naturally does do not match what you expect. I think\ngit-log (without any diff options nor paths limiter) to view the\nlinearlized sequence of commit messages is about the only thing\nthat makes some sense, and the size limit of Octopus would\nprobably end up to be the least of your problems.\n\nSo in that sense, I would very much more prefer the solution\nbased on \"the (single) tree object contained in the top-level\ncommit has pointers that point at commits of subprojects\"\napproach somebody (sorry I forgot who did this) proposed in the\npast (well, the very original idea was Linus's \"gitlink\" which\nis probably more than a year old).\n\nBefore concluding...\n\nYes, I am aware that you do not even intend to build on top of\nthe history of your imported-from-CVS, so in that sense, you do\nnot care about the ancestry of Hydra itself (it does not even\nhave a history -- just a single state). It's such a one-shot\nthing that we probably should not even care about (and your\ncommit-tree patch is fine -- I think the only thing in the core\ngit that cares about the maximum number of parents a commit can\nhave is git-blame), but I thought I should mention that it would\nbe an ideal application for a proper subproject support.\n"},{"id":"35587","messageId":"20070227105212.GA21757@coredump.intra.peff.net","threadId":"6971","inReplyTo":"7virdnhpbt.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFC/PATCH] commit-tree: bump MAX_PARENTS to 128","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-02-27T10:52:12Z","receivedAt":"2007-02-27T10:52:12Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Feb 27, 2007 at 02:23:02AM -0800, Junio C Hamano wrote:\n\n> I hate having to compose this message because I know I will end\n> up saying negative things without offering anything constructive.\n\nFirst off, thanks for a thoughtful and well-written response; it was, in\nfact, constructive in getting me to think about my setup. Subproject\nsupport is actually what I want here.\n\n> I do not think bundling commits from unrelated multiple projects\n> in one commit (some people seem to have called this Hydra in the\n> past) is a good practice, regardless of size.\n\nI'll assume by \"unrelated\" here you mean in the git sense; that is, not\nsharing any commit history. My projects are, in fact, semantically\nrelated. Let me describe a little further. I had a CVS repository\nconsisting of school work over the past several years, with one\ndirectory per class:\n\n school/cs101\n school/cs201\n etc.\n\nA year or so ago, I started using git, and imported all of my CVS repos\nto git. I did each class directory separately, reasoning that each\nrepresented a separate history. This can end up being unwieldy, because\nthere are dozens of repositories; I would now like to group them in the\nsame repo for ease of clone/fetch.\n\nSimilarly, each new class I take gets its own repo, which is quite\nconvenient when actively committing. However, I would like to \"archive\"\nit in the main repo.\n\nThus, I believe a central \"archive\" repo to which I could add\n\"subproject\" pointers to each class's commit history would be ideal.\nSomething like the gitlink or subproject support which has been talked\nabout would work fine.\n\nOTOH, I am fortunate that this is not a \"real\" distributed project. I\nthink the most convenient thing might be to simply rewrite the history\nof each class, pushing all of its files into a subdirectory from the\nmain history.\n\n> * You do not care about the ancestry of Hydra itself, so it has\n> two parents, then-current tips of A and B?\n\nThis is my case; the hydra had no history at all.\n\n> Now, do you have some files that are maintained by Hydra itself?\n\nNope. It's purely a set of subprojects.\n\n> Although pointers to component project commits are represented\n> as \"parent\" field in commit objects, I suspect that you wish\n> they were treated as if they were tree objects contained in the\n> toplevel commits more often than not for the purposes of many\n> git operations.\n\nYes, that is exactly correct. One problem I realized after doing this is\nthat you get unexpected results from \"git-whatchanged -- subproject/\".\nMy first expectation was to see _just_ the history of the subproject.\nBut of course, you see only the merge commit, since the previous commits\nfor that subproject didn't have that path at all (they were in the\nroot!). Subproject support would fix that, as would simply rewriting\nthe history.\n\n> I am not saying that the problem you are trying to solve is a\n> wrong problem. Rather, it is showing a gap between the\n> structure you are trying to express and the semantics of\n> ancestry chain git offers.\n\nAgreed. I have come around to the conclusion that this is an abuse of\nthe parent pointers.\n\n> Yes, I am aware that you do not even intend to build on top of\n> the history of your imported-from-CVS, so in that sense, you do\n> not care about the ancestry of Hydra itself (it does not even\n> have a history -- just a single state). It's such a one-shot\n\nI thought about that, too, but I actually _might_ want to make a commit\n(e.g., I'm keeping most of this around for reference code. If the\nreference code has a minor bug, it would be nice to fix it).\n\n\nAnyway, thanks for your comments. I think I will look at simply\nrewriting the history as if it were one big repository. I think it is\nsimplest in this case since I have the luxury of a private repo.\n\n-Peff\n"},{"id":"35589","messageId":"7v4pp7hnbs.fsf@assigned-by-dhcp.cox.net","threadId":"6971","inReplyTo":"20070227105212.GA21757@coredump.intra.peff.net","subject":"Re: [RFC/PATCH] commit-tree: bump MAX_PARENTS to 128","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-27T11:06:15Z","receivedAt":"2007-02-27T11:06:15Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Tue, Feb 27, 2007 at 02:23:02AM -0800, Junio C Hamano wrote:\n>\n>> Although pointers to component project commits are represented\n>> as \"parent\" field in commit objects, I suspect that you wish\n>> they were treated as if they were tree objects contained in the\n>> toplevel commits more often than not for the purposes of many\n>> git operations.\n>\n> Yes, that is exactly correct. One problem I realized after doing this is\n> that you get unexpected results from \"git-whatchanged -- subproject/\".\n> My first expectation was to see _just_ the history of the subproject.\n> But of course, you see only the merge commit, since the previous commits\n> for that subproject didn't have that path at all (they were in the\n> root!). Subproject support would fix that, as would simply rewriting\n> the history.\n\nFor the record, I am aware of the fact that the recent git.git\nitself exhibits this exact problem, due to the subtree merge of\ngit-gui repository. I haven't got to the point of being annoyed\nenough to regret it, but running \"git show\" on merges from Shawn\nalways needs -M option to make heads or tails of.\n"},{"id":"35591","messageId":"200702271131.57856.andyparkins@gmail.com","threadId":"6971","inReplyTo":"20070227105212.GA21757@coredump.intra.peff.net","subject":"Re: [RFC/PATCH] commit-tree: bump MAX_PARENTS to 128","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-02-27T11:31:52Z","receivedAt":"2007-02-27T11:31:52Z","isPatch":true,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Tuesday 2007 February 27 10:52, Jeff King wrote:\n\n> A year or so ago, I started using git, and imported all of my CVS repos\n> to git. I did each class directory separately, reasoning that each\n> represented a separate history. This can end up being unwieldy, because\n> there are dozens of repositories; I would now like to group them in the\n> same repo for ease of clone/fetch.\n\nIt doesn't have fetch or clone support, but perhaps my poorman's submodule \ncode will help you a bit, until real submodule support appears in git.\n\nhttp://marc2.theaimsgroup.com/?l=git&m=116662031219222&w=2\n\nI've found it useful for myself, and with a little bit of massaging I don't \nthink it would be hard to put fetch support in. I think it just needs a way \nof telling the remote end to switch GIT_DIR to a different directory.\n\n\"Merges\" are handled by simply sorting out any conflicts in the module file \n(basically you pick one of the submodule commits) just as you would with any \nother file.\n\nAs I say - not fabulous, but gets me by.\n\n\n\nAndy\n\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"35592","messageId":"20070227113938.GA5423@coredump.intra.peff.net","threadId":"6971","inReplyTo":"200702271131.57856.andyparkins@gmail.com","subject":"Re: [RFC/PATCH] commit-tree: bump MAX_PARENTS to 128","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-02-27T11:39:38Z","receivedAt":"2007-02-27T11:39:38Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Feb 27, 2007 at 11:31:52AM +0000, Andy Parkins wrote:\n\n> > there are dozens of repositories; I would now like to group them in the\n> > same repo for ease of clone/fetch.\n> \n> It doesn't have fetch or clone support, but perhaps my poorman's submodule \n> code will help you a bit, until real submodule support appears in git.\n\nThanks for the pointer, but it doesn't handle one of my pet peeves with\nmany repositories: fetching 25 repositories takes a long time. I have a\n\"look at every repository and see if anything needs fetched or pushed\"\nscript; it takes about 0.5-1.0 seconds per repository. Turning 25\nfetches into 1 makes it a lot nicer to use.\n\nSo of all the problems hoped to be solved by submodule support, I think\nyour poor man's submodule support solves the ones I don't care about\n(tracking external repositories with merge resolution) but not the one I\ndo (fetch/clone effort). :)\n\n-Peff\n"},{"id":"35615","messageId":"es1dm2$kt6$2@sea.gmane.org","threadId":"6971","inReplyTo":"20070227113938.GA5423@coredump.intra.peff.net","subject":"Re: [RFC/PATCH] commit-tree: bump MAX_PARENTS to 128","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-02-27T14:04:56Z","receivedAt":"2007-02-27T14:04:56Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jeff King wrote:\n\n> On Tue, Feb 27, 2007 at 11:31:52AM +0000, Andy Parkins wrote:\n> \n>>> there are dozens of repositories; I would now like to group them in the\n>>> same repo for ease of clone/fetch.\n>> \n>> It doesn't have fetch or clone support, but perhaps my poorman's submodule \n>> code will help you a bit, until real submodule support appears in git.\n> \n> Thanks for the pointer, but it doesn't handle one of my pet peeves with\n> many repositories: fetching 25 repositories takes a long time. I have a\n> \"look at every repository and see if anything needs fetched or pushed\"\n> script; it takes about 0.5-1.0 seconds per repository. Turning 25\n> fetches into 1 makes it a lot nicer to use.\n> \n> So of all the problems hoped to be solved by submodule support, I think\n> your poor man's submodule support solves the ones I don't care about\n> (tracking external repositories with merge resolution) but not the one I\n> do (fetch/clone effort). :)\n\nSee http://git.or.cz/gitwiki/SubprojectSupport which mentions prototype\nsubmodules/subprojects implementation by Martin Waitz, with having link\nto submodule commit in the tree (so tree have links to trees, to blobs,\nand to submodules/commits).\n\nBTW. Andy, could you add note about your lightweight submodule support\nto this page? TIA.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"35630","messageId":"Pine.LNX.4.63.0702271624000.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6971","inReplyTo":"7virdnhpbt.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFC/PATCH] commit-tree: bump MAX_PARENTS to 128","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-27T15:46:27Z","receivedAt":"2007-02-27T15:46:27Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 27 Feb 2007, Junio C Hamano wrote:\n\n> Jeff King writes:\n> \n> > On Tue, Feb 27, 2007 at 12:16:42AM -0800, Junio C Hamano wrote:\n> >\n> >> But as Shawn pointed out, Octopus makes bisect less (much less)\n> >> efficient for the end users, I tend to think the current 16 is\n> >> already insanely large.\n> >\n> > Did you look at my \"why I need a huge octopus\" description? Is there a \n> > better way to do it? Should I simply do a bunch of pair-wise merges? \n> > I'll almost certainly never bisect it,...\n> \n> I hate having to compose this message because I know I will end up \n> saying negative things without offering anything constructive.\n\nIMHO this discussion is anything but not constructive.\n\n> I do not think bundling commits from unrelated multiple projects in one \n> commit (some people seem to have called this Hydra in the past) is a \n> good practice, regardless of size.\n\nYesterday, I kicked an idea around on IRC with Sam: Darcs does not have \nbranches as we do. Sam was nice enough to show me a picture:\n\n\thttp://utsl.gen.nz/git/hydra-vs-regular.png\n\nFor those poor souls stuck with a text terminal, it looks like this:\n\nRight image:\n\nA-B-C-D-E-F-G-H-I-J-K-L-M-N-O-P-Q-R-S-T-U-V-W-X-Y-Z-a-b-c-d-e\n\nLeft image:\n\nA-B---------------------------------------------------------e\n |\n C F-G-H-I------------------------------------------/|\n |\\ | |\n | ---+-_ --J----------------------------------------/|\n \\ / --/ |\n D-E \\----K--------------------------------------/|\n \\ \\_ |\n \\ -L------------------------------------/|\n \\ |\n \\ M----------------------------------/|\n \\ |\n \\ P-----_ Y----------/|\n \\ | \\ / |\n --------------+-------T-U-V-W-X---Z---b-c--/|\n / | \\ / /\n N-O Q----/| ----------a d\n \\ |\n ----R--/|\n /\n S\n\n(Puh! Can you believe how much time such a picture takes?)\n\nSo, the right image is what it would look like of you just committed \neverything with Git, and the left image how it would look like with Darcs.\n\nNow, I never have worked with Darcs, but I _could_ imagine that it would \nbe useful for some workflows to generate the Darcs layout automatically \nfrom the Git layout. In that case, a _lot_ of parents should be allowed.\n\nCiao,\nDscho\n"}]}