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

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Fri, Nov 05 2021, 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 is a known caveat of how the history traversal works, but from a
quick glance I couldn't see any explicit documentation for it, aside
from this terse mention in git-log(1):

     "[-M can be used] for following files across renames while
     traversing history, see --follow.".

The key thing being the "traversal", i.e. as we walk history we'll
encounter a tree entry where b.txt was deleted, and see that it was
moved from a.txt.

However, if we walk history from the beginning we have no idea of the
relationship of a->b.txt, since we didn't encounter that commit yet,
that's only something we see while walking the history.

Perhaps we should have some option like --buffer-then-reverse, which
wouldn't change the walking order, but would only change the output, but
we don't.

This caveat doesn't only apply to reverse, try to apply a move of b.txt
on top of your history:

    b.txt -> c.txt

And now do:

    git log [--follow] -- b.txt

What should we output there? If we're arguing that we should first
traverse the history to "look forward" that'll also apply to a
non-reverse walk, since we're asking to follow b.txt.

But we haven't encountered the b->c.txt relationship yet (well, we run
into the rename commit, but once you add a c->d.txt on top...). So maybe
instead of --buffer-then-reverse we'd need a hypothetical --two-pass,
which would also impact options other than --reverse whose behavior
relies on traversal order.

Take all the above as an explanation for how it works now, not some
defense of this being user-friendly. I've also often been annoyed at
this behavior.

For small sets you can feed your into an alias like:

    git show $(git -P log --pretty=format:"%h" --pretty=tformat:%H --follow -- b.txt | tac)

As a poor man's --buffer-then-reverse.