Styjun

If a file, A, is edited one or more times, then renamed/moved to B and edited one or more times as B, issuing the following git command using its new name/path ...

git log --follow -- B

... shows its entire history.

However, when I'm looking at an old (released/maintained) branch of the same project where the file is still named A and I want to backport changes done to it in master, I might think that issuing the following on master ...

git log --follow -- A

... will show me all changes. But it does not. The latest commit displayed in the log is the change corresponding to the rename from A to B. Changes done to B are not shown.

i.e. --follow only follows renames "backwards" from a newer name to an older one, but not "forwards".

At this point, I have to first identify that the latest commit displayed is a rename, find the newer name, and issue a git log --follow again with the new name (and potentially repeat this several times if the file was moved around a few times since the maintained release.

How can I find the entire history without having to manually issue git log --follow several times?

Unfortunately, git log itself strictly works backwards, as Git always does. Git literally cannot work forwards because what Git has stored is backwards: each commit remembers the hash ID of its parent commit, but since all commits are frozen in time the moment they are created, they cannot remember the hash IDs of their children, who are created later.

What git log (and its sort of big sister / workhorse plumbing command git rev-list) can do is do this reverse traversal once, figuring out which commits go before which other commits, then print in reverse. The git log --reverse command does this. But alas, rename detection happens only during the backwards (which to Git is forwards) traversal and cannot be wedged into the later forwards (which to Git is backwards) printout.

It's not built in to Git, but you can use git rev-list to do the reversal, save the result, then do your own forwards walk while running git diff --name-status on each commit pair, looking for rename operations. Note that this is still a bit tricky since now branches really branch and merges really merge—in Git's internal backwards traversals, merges branch, while branches merge. :-) That is, suppose we have:

 tag:abc
 |
 v
...--o--o--*--o--o--o <-- tip1
 
 o--*--o----o <-- tip2

You want to start from tag abc, which is on the left, and "work forwards". Git wants to start from either tip1, the commit towards the right along the top line, or tip2, the commit towards the right on the bottom line.

The commits marked * rename your file A to some new name. In the one along the top the new name is B and in the one along the bottom the new name is C.

If you start Git at tip2, you must look for C. Git notices the rename in * and from then on, towards the left, looks for A. If you start Git at tip1, you must look for B, in the same fashion.

If you've built a "forwards" listing by going backwards from tip1 to some point before tag abc, you'll be OK: there's no branch in that listing since none of the commits leading to tip2 are included. But then suppose someone adds a merge to tip1, and another commit:

 tag:abc
 |
 v
...--o--o--*--o--o--o--M--o <-- tip1
 /
 o--*--o----o <-- tip2

Now the path from abc to tip1 includes both renames. If you start at tip1 you must give git log --follow the name that whoever did the merge chose to keep, whether that's B or C. Because git log -- B or git log -- C (whichever is the right name) does history simplification, Git is going to walk only one of the two legs behind M–either the top or bottom row, depending on which one has the matching file—and when you work forwards from abc you'll have to pick one of the two branches to work along, or do something fancy so that you know to check for A-becomes-B along the top while also checking for A-becomes-C along the bottom. (Git doesn't do anything fancy.)