Why might git log not show history for a moved file, and what can I do about it?

Question

I've renamed a couple of files using git mv, used git stash, had a quick look at HEAD (without changing it) then did git stash pop to get the whole lot back again. My moves had disappeared from the commit list, so I redid them with git rm and the commit message claimed git had spotted the rename was a rename. So I thought no more of it.

But now, post-commit, I can't get at the history of the moved files! Here's what git says about the commit in question:

~/projects% git log --summary
commit de6e9fa2179ae17ec35a5c368d246f19da27f93a
Author: brone
Date:   Wed Dec 8 22:37:54 2010 +0000

    Moved R_DebugUI into runtime

 delete mode 100644 test/R_DebugUI_iOS.h
 delete mode 100644 test/R_DebugUI_iOS.m
 create mode 100644 system/runtime/src/R_DebugUI_iOS.h
 create mode 100644 system/runtime/src/R_DebugUI_iOS.m

 <<snip older commits>>
 ~/projects%

I'm now trying to get the history of one of these moved files, so I can look at an old version, but I don't get anything very useful:

~/projects/system/runtime/src% git log --follow --find-copies-harder -M -C R_DebugUI_iOS.m
commit de6e9fa2179ae17ec35a5c368d246f19da27f93a
Author: brone
Date:   Wed Dec 8 22:37:54 2010 +0000

    Moved R_DebugUI into runtime
~/projects/system/runtime/src% 

(I've also tried it without -M, -C and --find-copies-harder, but to no avail.)

I can get its history under its old name, which stops at the point it was deleted from its old location:

~/projects% git log --summary --follow --find-copies-harder -M -C -- test/R_DebugUI_iOS.m
commit de6e9fa2179ae17ec35a5c368d246f19da27f93a
Author: brone
Date:   Wed Dec 8 22:37:54 2010 +0000

    Moved R_DebugUI into runtime

 delete mode 100644 test/R_DebugUI_iOS.m

commit 32a22d53c27e260714f759ecb3d3864e38b2e87f
Author: brone
Date:   Tue Dec 7 23:52:51 2010 +0000

    Can set debug UI's alpha.

<<snip older commits>>
~/projects%

So I'm not completely stuck this time, but I wouldn't fancy having to do this kind of thing all the time. (I anticipate having a fair number of files that will move at least once in their life.)

Am I doing something wrong? The old copy of the file and the new copy are 98.8% the same (2 lines out of 166 changed). My understanding is that git should be able to track the file in this case, because it infers rename operations rather than storing them explicitly, and the files are similar enough that I believe it should consider them the same.

Is there anything I can do to fix this?

Scrotum

Guess: Does it work if you execute the command inside ~/projects/ instead of ~/projects/system/runtime/src? – Djokjakarta

No, I get the same result. (Generally git seems pretty good about letting you be in any folder anyway...) – Scrotum

That gave me an idea though, and I updated the question with my findings. Thanks for the comment! – Scrotum

i am using "tortoiseGit 1.5.8.0" together with "1.7.3.1.msysgit.0" on mswindows. When i rename+commit a file in explorer i see in my gui "status=Rename". I donot know enough about git how to do this in commandline to answer "how to do that" but tortoiseGit did something for me that worked as you expected. – Bedad

Is this a dupe? #2315152 – Descend

Answer 1

Answering my own question, since I have managed to assuage my concerns, even if I haven't solved my problem exactly. (git log --follow still doesn't work for me, though.)

Firstly, the --summary log for the renaming commit includes the delete line with the file's old name. So if it's easy to spot, you can find its old name and git log from there.

If it's part of some large commit, and therefore a bit harder to spot -- and this situation was one of my worries -- git blame -C can be used with the file's new name on the first post-rename revision. Presumably lines remain from the original file! -- so git should find their source, and show old file name (and a commit hash for good measure). You can then pick up the trail with git log.

So, if you have some interest in the history of the file as a unit (for whatever reason) then it seems like it can be done relatively straightforwardly. Though I get the impression git would prefer that you used it properly.

Scrotum

I think you need the -M option to actually show renames rather than delete/add's – Shigella

Just had the same problem and noticed that your working directory makes a difference git log --follow . where the working directory is the new location does not work, while git log --follow path/to/new/dir, executed from a common parent directory of the old and the new location, works – Daune

The --follow parameter does work, but you need to do: git log --follow -- ./path/to/file – Susy

I've just got the problem that git -log filename.cs stops on file movement commit (current dir is set to the file's folder). However VS history window shows the whole file change log. Also I can see that file has been moved with Github desktop. But git log -10 --follow filename.cs shows the log before move commit too. – Marleenmarlen

Answer 2

Try git log --follow on your file.
Is it possible to move/rename files in Git and maintain their history?

Galbreath

If you get fatal: ambiguous argument 'file.txt': unknown revision or path not in the working tree, try git log --follow -- file.txt – Circular

Answer 3

Well, I do see my renames with git log -M --summary..

Snigger

git log -M --summary doesn't give any rename information if you're just looking at the history of some given file, i.e. with a file argument. – Neace

Does not work for me, but --follow does. --follow shows also previous revisions before the file was moved/renamed. – Passable

Answer 4

git log --follow ./path/to/file

I believe this is what you're looking for.

Eyesore

The answer from five years prior has this information. – Turbulent

Answer 5

as already mentioned:

git log --follow ./file

is working.

If you find it useful and don't want to type it everytime at git log, set this config option:

git config log.follow true

Dybbuk