{"thread":{"id":"3458","subject":"Removal of \"--merge-order\"?","startedAt":"2006-02-24T16:32:43Z","lastAt":"2006-02-24T21:37:38Z","messageCount":9,"participants":["Linus Torvalds","Randy.Dunlap","Ryan Anderson","Junio C Hamano","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"16684","messageId":"Pine.LNX.4.64.0602240824110.3771@g5.osdl.org","threadId":"3458","inReplyTo":null,"subject":"Removal of \"--merge-order\"?","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-02-24T16:32:43Z","receivedAt":"2006-02-24T16:32:43Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\nI just tested it again, and\n\n\tgit-rev-list --merge-order HEAD\n\ntakes an inordinate amount of time:\n\n\treal    5m1.139s\n\tuser    4m59.504s\n\tsys     0m1.220s\n\nand that's on a reasonably fast machine (not my fastest, but no slouch by \nany measure - my fastest machine I'm not allowed to really benchmark \npublicly ;)\n\nIt may be a cool algorithm, but it's essentially useless on any bigger \ntree. And nobody uses it, since \"--topo-order\" gives the guarantees that \npeople really care about, and finishes in 0.537 seconds on the same \nmachine with the same tree.\n\nIt also depends on the openssh \"bignum\" stuff, which means that any \nmachine where we just rely on our own SHA1 implementation and don't use \nopenssh doesn't have the flag anyway.\n\nIn other words, I'd really prefer if it was gone. Some of the things I \nmight do to git-rev-list would be much simpler if I didn't have to worry \nabout merge-order, and the way it interfaces with the rest of \ngit-rev-list.\n\nComments?\n\n\t\t\tLinus\n"},{"id":"16685","messageId":"Pine.LNX.4.58.0602240840520.7894@shark.he.net","threadId":"3458","inReplyTo":"Pine.LNX.4.64.0602240824110.3771@g5.osdl.org","subject":"Re: Removal of \"--merge-order\"?","fromName":"Randy.Dunlap","fromEmail":"rdunlap@xenotime.net","sentAt":"2006-02-24T16:53:00Z","receivedAt":"2006-02-24T16:53:00Z","isPatch":false,"sender":{"key":"rdunlap@xenotime.net","avatar":null},"body":"On Fri, 24 Feb 2006, Linus Torvalds wrote:\n\n>\n> I just tested it again, and\n>\n> \tgit-rev-list --merge-order HEAD\n>\n> takes an inordinate amount of time:\n>\n> \treal    5m1.139s\n> \tuser    4m59.504s\n> \tsys     0m1.220s\n\nThat's too bad.\n\n> and that's on a reasonably fast machine (not my fastest, but no slouch by\n> any measure - my fastest machine I'm not allowed to really benchmark\n> publicly ;)\n>\n> It may be a cool algorithm, but it's essentially useless on any bigger\n> tree. And nobody uses it, since \"--topo-order\" gives the guarantees that\n> people really care about, and finishes in 0.537 seconds on the same\n> machine with the same tree.\n>\n> It also depends on the openssh \"bignum\" stuff, which means that any\n> machine where we just rely on our own SHA1 implementation and don't use\n> openssh doesn't have the flag anyway.\n>\n> In other words, I'd really prefer if it was gone. Some of the things I\n> might do to git-rev-list would be much simpler if I didn't have to worry\n> about merge-order, and the way it interfaces with the rest of\n> git-rev-list.\n>\n> Comments?\n\nI'm just a lowly user, but I see people trying to export git\ntrees to other SCMs, and they seem to prefer merge-order.\nThis is your chance to correct me about:\n(a) how I am wrong; (b) how they are wrong.  8;)\n\nI've heard/seen you say that merge-order is not interesting,\nbut I still believe that *your* merge order of the Linux kernel\ntree is almost all that people really care about.\nApparently I needed to go to LCA to hear you discuss git.\n\n-- \n~Randy\n"},{"id":"16686","messageId":"Pine.LNX.4.64.0602240918030.3771@g5.osdl.org","threadId":"3458","inReplyTo":"Pine.LNX.4.58.0602240840520.7894@shark.he.net","subject":"Re: Removal of \"--merge-order\"?","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-02-24T17:23:24Z","receivedAt":"2006-02-24T17:23:24Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 24 Feb 2006, Randy.Dunlap wrote:\n> \n> I'm just a lowly user, but I see people trying to export git\n> trees to other SCMs, and they seem to prefer merge-order.\n> This is your chance to correct me about:\n> (a) how I am wrong; (b) how they are wrong.  8;)\n\nWell, I didn't even realize anybody at all was using it. I've never seen \nany mention of it, and considering how ungodly slow it is, I would have \nexpected somebody to pipe up about it..\n\nI did a google search for \"git\" and \"merge-order\", and the only actual use \n(as opposed to mention in a man-page) I found in the 20 hits google showed \nwas an old version of gitk.\n\n> I've heard/seen you say that merge-order is not interesting,\n> but I still believe that *your* merge order of the Linux kernel\n> tree is almost all that people really care about.\n\nCould you actually point to somebody using it? They're hiding it well.\n\n> Apparently I needed to go to LCA to hear you discuss git.\n\nI certainly never delved into any of that.. \n\n\t\tLinus\n"},{"id":"16687","messageId":"20060224173258.GA16500@mythryan2.michonline.com","threadId":"3458","inReplyTo":"Pine.LNX.4.64.0602240918030.3771@g5.osdl.org","subject":"Re: Removal of \"--merge-order\"?","fromName":"Ryan Anderson","fromEmail":"ryan@michonline.com","sentAt":"2006-02-24T17:32:58Z","receivedAt":"2006-02-24T17:32:58Z","isPatch":false,"sender":{"key":"ryan@michonline.com","avatar":null},"body":"On Fri, Feb 24, 2006 at 09:23:24AM -0800, Linus Torvalds wrote:\n> On Fri, 24 Feb 2006, Randy.Dunlap wrote:\n> > \n> > I'm just a lowly user, but I see people trying to export git\n> > trees to other SCMs, and they seem to prefer merge-order.\n> > This is your chance to correct me about:\n> > (a) how I am wrong; (b) how they are wrong.  8;)\n> \n> Well, I didn't even realize anybody at all was using it. I've never seen \n> any mention of it, and considering how ungodly slow it is, I would have \n> expected somebody to pipe up about it..\n> \n> I did a google search for \"git\" and \"merge-order\", and the only actual use \n> (as opposed to mention in a man-page) I found in the 20 hits google showed \n> was an old version of gitk.\n\nhttp://www.gelato.unsw.edu.au/archives/git/0511/12965.html\n\nBut topo-order would probably work as well, the default ordering just\ndidn't work correctly in my tests.\n\nCertainly not a case that votes *against* removal, just noting an actual\nuser at one point.\n\n-- \n\nRyan Anderson\n  sometimes Pug Majere\n"},{"id":"16689","messageId":"Pine.LNX.4.58.0602240942520.7894@shark.he.net","threadId":"3458","inReplyTo":"Pine.LNX.4.64.0602240918030.3771@g5.osdl.org","subject":"Re: Removal of \"--merge-order\"?","fromName":"Randy.Dunlap","fromEmail":"rdunlap@xenotime.net","sentAt":"2006-02-24T17:47:14Z","receivedAt":"2006-02-24T17:47:14Z","isPatch":false,"sender":{"key":"rdunlap@xenotime.net","avatar":null},"body":"On Fri, 24 Feb 2006, Linus Torvalds wrote:\n\n>\n>\n> On Fri, 24 Feb 2006, Randy.Dunlap wrote:\n> >\n> > I'm just a lowly user, but I see people trying to export git\n> > trees to other SCMs, and they seem to prefer merge-order.\n> > This is your chance to correct me about:\n> > (a) how I am wrong; (b) how they are wrong.  8;)\n>\n> Well, I didn't even realize anybody at all was using it. I've never seen\n> any mention of it, and considering how ungodly slow it is, I would have\n> expected somebody to pipe up about it..\n>\n> I did a google search for \"git\" and \"merge-order\", and the only actual use\n> (as opposed to mention in a man-page) I found in the 20 hits google showed\n> was an old version of gitk.\n>\n> > I've heard/seen you say that merge-order is not interesting,\n> > but I still believe that *your* merge order of the Linux kernel\n> > tree is almost all that people really care about.\n>\n> Could you actually point to somebody using it? They're hiding it well.\n\nOther than Ryan's reply, I found 2 users in a quick search,\nbut they have already stated that they are willing to change, so I\ndon't see objections unless someone else comes forward.\n\n(Martin Langhoff, archimport)\nhttp://marc.theaimsgroup.com/?l=git&m=112682069025547&w=2\nJon Seymour:\nhttp://marc.theaimsgroup.com/?l=git&m=112998877717814&w=2\n\n> > Apparently I needed to go to LCA to hear you discuss git.\n>\n> I certainly never delved into any of that..\n\nDarn.\n\n-- \n~Randy\n"},{"id":"16692","messageId":"Pine.LNX.4.64.0602240957430.22647@g5.osdl.org","threadId":"3458","inReplyTo":"Pine.LNX.4.58.0602240942520.7894@shark.he.net","subject":"Re: Removal of \"--merge-order\"?","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-02-24T18:07:12Z","receivedAt":"2006-02-24T18:07:12Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 24 Feb 2006, Randy.Dunlap wrote:\n>\n> Other than Ryan's reply, I found 2 users in a quick search,\n> but they have already stated that they are willing to change, so I\n> don't see objections unless someone else comes forward.\n\nOne thing we could do - and might be simpler - is to make the merge-order \nthing be a post-processing phase of git-rev-list.\n\nIOW, instead of\n\n\tgit-rev-list --merge-order\n\nwe could perhaps do\n\n\tgit-rev-list --parents [--topo-order?] | git-merge-order\n\nso that the merge-order code wouldn't impact git-rev-list itself.\n\nAs it is, the merge-order code ends up hooking into the \"process_commit\" \nthing (and thus to \"filter_commit\" which does the parent rewriting, and \nthen show_commit), which makes it harder to work with.\n\nNow, rev-list.c is not the biggest file (apply.c is about twice the size), \nbut in many ways it's the most complex one by far. It's also the most \nperformance-critical one, and the one that it would be really nice if we \nwere to be able to libify it.\n\nFor example, instead of the horrid scriping language, I _think_ I could \nalmost libify it by just hooking into \"show_commit\", and using a callback \nfunction for that (and then the stand-alone program would just make the \ncallback function be one that prints out the commit). \n\nWith some care, we might be able to make things like \"git diff\" be small C \nprograms (or, more likely, to save space and not replicate the binaries \nmany times - make the \"git\" binary able to do all the simple things on its \nown: \"git-diff\" would be just a link to \"git\").\n\nThat would possibly be a simpler way to get away from using nonportable \nscripts. Plain C really does remain one of the most portable things out \nthere.\n\n\t\t\tLinus\n"},{"id":"16693","messageId":"Pine.LNX.4.58.0602241008590.7894@shark.he.net","threadId":"3458","inReplyTo":"Pine.LNX.4.64.0602240957430.22647@g5.osdl.org","subject":"Re: Removal of \"--merge-order\"?","fromName":"Randy.Dunlap","fromEmail":"rdunlap@xenotime.net","sentAt":"2006-02-24T18:10:32Z","receivedAt":"2006-02-24T18:10:32Z","isPatch":false,"sender":{"key":"rdunlap@xenotime.net","avatar":null},"body":"On Fri, 24 Feb 2006, Linus Torvalds wrote:\n\n>\n>\n> On Fri, 24 Feb 2006, Randy.Dunlap wrote:\n> >\n> > Other than Ryan's reply, I found 2 users in a quick search,\n> > but they have already stated that they are willing to change, so I\n> > don't see objections unless someone else comes forward.\n>\n> One thing we could do - and might be simpler - is to make the merge-order\n> thing be a post-processing phase of git-rev-list.\n>\n> IOW, instead of\n>\n> \tgit-rev-list --merge-order\n>\n> we could perhaps do\n>\n> \tgit-rev-list --parents [--topo-order?] | git-merge-order\n>\n> so that the merge-order code wouldn't impact git-rev-list itself.\n\nMakes sense to me... thanks.\nBut even that may not be needed if noone else really needs it.\n\n> As it is, the merge-order code ends up hooking into the \"process_commit\"\n> thing (and thus to \"filter_commit\" which does the parent rewriting, and\n> then show_commit), which makes it harder to work with.\n>\n> Now, rev-list.c is not the biggest file (apply.c is about twice the size),\n> but in many ways it's the most complex one by far. It's also the most\n> performance-critical one, and the one that it would be really nice if we\n> were to be able to libify it.\n>\n> For example, instead of the horrid scriping language, I _think_ I could\n> almost libify it by just hooking into \"show_commit\", and using a callback\n> function for that (and then the stand-alone program would just make the\n> callback function be one that prints out the commit).\n>\n> With some care, we might be able to make things like \"git diff\" be small C\n> programs (or, more likely, to save space and not replicate the binaries\n> many times - make the \"git\" binary able to do all the simple things on its\n> own: \"git-diff\" would be just a link to \"git\").\n>\n> That would possibly be a simpler way to get away from using nonportable\n> scripts. Plain C really does remain one of the most portable things out\n> there.\n\n-- \n~Randy\n"},{"id":"16700","messageId":"7v8xs0a7a3.fsf@assigned-by-dhcp.cox.net","threadId":"3458","inReplyTo":"Pine.LNX.4.64.0602240824110.3771@g5.osdl.org","subject":"Re: Removal of \"--merge-order\"?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-24T19:25:24Z","receivedAt":"2006-02-24T19:25:24Z","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> In other words, I'd really prefer if it was gone. Some of the things I \n> might do to git-rev-list would be much simpler if I didn't have to worry \n> about merge-order, and the way it interfaces with the rest of \n> git-rev-list.\n>\n> Comments?\n>\n> \t\t\tLinus\n\nI am really glad you brought it up.  I would not miss it at all.\n"},{"id":"16711","messageId":"Pine.LNX.4.63.0602242230210.11479@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"3458","inReplyTo":"Pine.LNX.4.64.0602240957430.22647@g5.osdl.org","subject":"Re: Removal of \"--merge-order\"?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-02-24T21:37:38Z","receivedAt":"2006-02-24T21:37:38Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 24 Feb 2006, Linus Torvalds wrote:\n\n> Now, rev-list.c is not the biggest file (apply.c is about twice the size), \n> but in many ways it's the most complex one by far. It's also the most \n> performance-critical one, and the one that it would be really nice if we \n> were to be able to libify it.\n\nThis is what I wanted to try today, but unfortunately I had to do real \nwork :-(\n\n> For example, instead of the horrid scriping language, I _think_ I could \n> almost libify it by just hooking into \"show_commit\", and using a callback \n> function for that (and then the stand-alone program would just make the \n> callback function be one that prints out the commit). \n\nI don't find the scripting language you invented particularly horrid. \nMaybe some odd things (like \"if\" branching to the \"else\" block whenever \n*any* argument was passed), but not horrid.\n\nBut in the end I would prefer a libified git, if only to get rid of \ndouble parsing (if you pipe the output of git-rev-list to another git \nprogram, chances are that you parse the commit objects at least twice).\n\n> That would possibly be a simpler way to get away from using nonportable \n> scripts. Plain C really does remain one of the most portable things out \n> there.\n\nYes.\n\nCiao,\nDscho\n"}]}