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

From: Linus Torvalds <torvalds@osdl.org>
Date: Feb 24, 2006, 18:07 UTC
Message-ID: <Pine.LNX.4.64.0602240957430.22647@g5.osdl.org>
In-Reply-To: <Pine.LNX.4.58.0602240942520.7894@shark.he.net>

On Fri, 24 Feb 2006, Randy.Dunlap wrote:

>
> Other than Ryan's reply, I found 2 users in a quick search,
> but they have already stated that they are willing to change, so I
> don't see objections unless someone else comes forward.

One thing we could do - and might be simpler - is to make the merge-order thing be a post-processing phase of git-rev-list.

IOW, instead of

	git-rev-list --merge-order

we could perhaps do

	git-rev-list --parents [--topo-order?] | git-merge-order

so that the merge-order code wouldn't impact git-rev-list itself.

As it is, the merge-order code ends up hooking into the "process_commit" thing (and thus to "filter_commit" which does the parent rewriting, and then show_commit), which makes it harder to work with.

Now, rev-list.c is not the biggest file (apply.c is about twice the size), but in many ways it's the most complex one by far. It's also the most performance-critical one, and the one that it would be really nice if we were to be able to libify it.

For example, instead of the horrid scriping language, I _think_ I could almost libify it by just hooking into "show_commit", and using a callback function for that (and then the stand-alone program would just make the callback function be one that prints out the commit).

With some care, we might be able to make things like "git diff" be small C programs (or, more likely, to save space and not replicate the binaries many times - make the "git" binary able to do all the simple things on its own: "git-diff" would be just a link to "git").

That would possibly be a simpler way to get away from using nonportable scripts. Plain C really does remain one of the most portable things out there.

			Linus