On Sun, 9 Apr 2006, Junio C Hamano wrote: > > Also, I might have to rethink --max-count logic -- I think it is > reasonable to skip the commit when doing limiting by diff like > "whatchanged" does, but one thing I find suboptimal with the > current whatchanged is that it does not count commits that are > actually shown (it counts what the upstream rev-list feeds > diff-tree). With the "git log --diff" based whatchanged, it > becomes trivial to skip the revs->max_count limiting and have > the caller count the commits it actually does something > user-visible to, instead of counting the commits it pulled out > of get_revision(). Well, on the other hand, the new "git log --diff" should get the revision counting right even if it's _not_ done by the caller. Really, the only reason "git-whatchanged" exists at all is that it used to be originally impossible, and later on too expensive to do the commit- limiting by pathname. With the new incremental path-limiting, the reason for "git-whatchanged" simply goes away. So I'd suggest: - drop git-whatchanged entirely - keep it - for historical reasons - as a internal shorthand, and just turn it into "git log --diff -cc" and everybody will be happy (yeah, it will show a few merge commits without diffs, because the diffs end up being uninteresting, but that's _fine_, even if it's not 100% the same thing git-whatchanged used to do) 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