On Tue, 28 Feb 2006, Linus Torvalds wrote: > > Again, this may not do exactly what the current "git log" does. That's not > the point. The point is to introduce the fundamental functionality, so > that people can play with this and improve on it, and fix any of my stupid > bugs. Btw, before anybody even pipes up: the missing piece here is the nasty "filter_commit()" that rev-list.c does, and that really should be moved into revision.c, and this is where I hit on the "--merge-order" issues. So for example, if you do "git log -- <filename>" with the new git, it won't filter out the commits that just change the passed-in <filename> properly, because the filtering code still exists only in git-rev-list (even if revision.c now does the traversal). Same goes for the max-count-based filtering, for the same reason. So the "process_commit()" handling should be moved into "get_revision()", but since the merge-order code also hooks into it... Anyway, apart from that issue (which I think should be trivial to sort out if we accept breaking --merge-order), the rest looks like it should just get more testing and handling of the few missing flags from rev-parse in revision.c, and it should be good. 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