Re: Removal of "--merge-order"?

From: Randy.Dunlap <rdunlap@xenotime.net>
Date: Feb 24, 2006, 16:53 UTC
Message-ID: <Pine.LNX.4.58.0602240840520.7894@shark.he.net>
In-Reply-To: <Pine.LNX.4.64.0602240824110.3771@g5.osdl.org>

On Fri, 24 Feb 2006, Linus Torvalds wrote:

Show 10 quoted lines

>
> 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.

Show 19 quoted lines

> 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