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
