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
