Jeff King <p...@peff.net> writes: > But does this catch all of the limiting that git-log would do? I notice > that it happens before the call to log_tree_diff(), which conditionally > returns a "shown" flag. So you get weird results with some options. For > example: > > # works, because pathspec limiting happens early > git log --count builtin/log.c > > # doesn't work, because --follow disables pruning > git log --follow --count builtin/log.c
Well, that's a bad one. > I know "--follow" is a bit hacky in general, but I think there are other > cases where log_tree_diff() may decide not to show a commit (maybe > without --root, though I guess that's the default these days). > > I dunno. Certainly respecting "--count" even for the simple cases is an > improvement over the status quo. Maybe it would be enough to give a > warning in the manpage that it may not work with exotic options. Hmph, perhaps. I wonder if it is easy enough to redirect the entire codeflow to that of rev-list when we see --count in cmd_log().
