On Fri, 24 Feb 2006, Linus Torvalds wrote: > > I just tested it again, and > > git-rev-list --merge-order HEAD > > takes an inordinate amount of time: > > real 5m1.139s > user 4m59.504s > sys 0m1.220s That's too bad. > and that's on a reasonably fast machine (not my fastest, but no slouch by > any measure - my fastest machine I'm not allowed to really benchmark > publicly ;) > > It may be a cool algorithm, but it's essentially useless on any bigger > tree. And nobody uses it, since "--topo-order" gives the guarantees that > people really care about, and finishes in 0.537 seconds on the same > machine with the same tree. > > It also depends on the openssh "bignum" stuff, which means that any > machine where we just rely on our own SHA1 implementation and don't use > openssh doesn't have the flag anyway. > > In other words, I'd really prefer if it was gone. Some of the things I > might do to git-rev-list would be much simpler if I didn't have to worry > about merge-order, and the way it interfaces with the rest of > git-rev-list. > > Comments? I'm just a lowly user, but I see people trying to export git trees to other SCMs, and they seem to prefer merge-order. This is your chance to correct me about: (a) how I am wrong; (b) how they are wrong. 8;) I've heard/seen you say that merge-order is not interesting, but I still believe that *your* merge order of the Linux kernel tree is almost all that people really care about. Apparently I needed to go to LCA to hear you discuss git. -- ~Randy - : send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html