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

[Vipul Kumar <kumar@onenetbeyond.org>]

On 11/5/21 8:17 AM, Jeff King wrote:

> 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").

I think, it's a good idea to disallow the combination of "--reverse" and 
"--follow", just like we did for "--reverse" and "--walk-reflogs" 
combination. Because this combination never going to help anybody:

   * If there is nothing to follow, people shouldn't use "--follow" 
option. Using "--follow" along with "--reverse" might arise 
misconception to users that they are also following renames also, which 
actually they don't.

   * But if there are things to follow, using combination of "--follow" 
and "--reverse" only shows a single commit which points to the "rename 
of the file". I quite didn't understand why is this happening? Once we 
encounter rename commit (from "a.txt to b.txt") while traversing in 
reverse order, our pathspec is now "b.txt". So we should also get list 
of commits which changes b.txt file.

> As a workaround, you can get what you want by two separate traversals:
> 
>    git log --follow --format=%H -- $your_file |
>    git log --stdin --no-walk --reverse [--oneline, -p, etc]

Thank you!


-v