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