Re: List all commits of a specified file in oldest to newest order

[Jeff King <peff@peff.net>]

On Fri, Nov 05, 2021 at 04:10:31AM +0000, Vipul Kumar wrote:

> I want to list all commits (including renames) of a specified file in oldest
> to newest order. But when I run "git log --follow --reverse --
> <path/to/the/file>" command, I'm getting a single commit, which points to
> the "rename of the file". This behavior is weird to me because I expected to
> get list of all commit in oldest to newest order, whereas "git log --follow
> -- <path/to/the/file>" command works as expected.

This has to do with the hacky way --follow is implemented. We don't
compute the full set of commits to show ahead of time, but rather as we
traverse, we change which pathspec we'll match when we hit a commit that
has a rename. Whereas --reverse is applied before we even start the main
traversal, and instead collect all possible commits and then walk them
in reverse order.

So the very first commit we'll look at for --follow is the one that
created the file from the rename, at which point we'll start looking
only for the old name. But of course all of the other commits post-date
the rename, so they don't use that old name.

So yes, it's a bug in the sense that the behavior is nonsense and it
doesn't work as one might expect. But it's also the hacky "--follow"
working as designed, and is just a limitation of its approach. It would
need to be rewritten completely to work correctly.  Arguably we should
at least disallow the combination of --reverse and --follow for now, as
it will never help (OTOH, if there is nothing to follow it should behave
OK, and I suspect some people and scripts may add --follow "just in
case").

As a workaround, you can get what you want by two separate traversals:
one to collect the commits via --follow, and then another to actually
show them (but without doing any further walking). Like:

  git log --follow --format=%H -- $your_file |
  git log --stdin --no-walk --reverse [--oneline, -p, etc]

-Peff