On Sun, 9 Apr 2006, Junio C Hamano wrote: > Linus Torvalds <torvalds@xxxxxxxx> writes: > > > 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. > > Not if the user uses --diff-filter and/or --pickaxe, and after > we start omitting the log message part when no diff is output. Fair enough. At that point the counting does have to be done in the caller, I guess. > A merge commit touching a path but not actually changing the contents of > the path from parents might be a significant event. Yes. The fact that git-whatchanged happens to ignore such things right now is just a implementation detail, not a "good thing". The new git log seems to be better in pretty much all respects. The bigger conceptual difference is actually that once you do revision pruning based on the pathname limiter, we prune away parents of merges that seem "uninteresting". So before, when you had the same change come through two different branches, "git-whatchanged" would actually show it twice, while the new "git log" approach would tend to show it just once (because it would pick one of the histories and ignore the other). I think that's fine (and probably even preferable), but it's another example of something where we might want to have an option to not simplify the merge history. It's likely that nobody will ever care, but who knows.. 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