26

Since it is no longer in the repository, I can't do

git log <filename>

I can run

git log  --diff-filter='D|R' <directory_that_contained_it>

but that is too much information and grepping it does not seem to list the file I'm looking for.

Balint Erdi
  • 1,103
  • 2
  • 12
  • 20

2 Answers2

31
git log -1 --stat -- <path/to/file>

I put the --stat in there so that you can verify that the file was deleted.

Giorgos Kylafas
  • 2,243
  • 25
  • 25
  • Interesting. That was the first thing I tried (without the --stat) and it did not work. I've now tried with another repo and it works there. However, it still does not for the original repo. It gives back nothing as if the file had never existed. If I go back to the commit that deleted the file it works but not from the current HEAD. – Balint Erdi Mar 13 '12 at 09:33
  • It doesn't give anything. – MKumar Jun 13 '13 at 12:32
  • 2
    @BalintErdi I am not sure this will work in situations where the hash id that deleted the file came before the last hash id to touch the file, as is possible when doing a merge between two branches. -- So, this may explain why it doesn't work consistently for you. – John Zabroski Aug 13 '15 at 12:26
4
git log -- <filename>

will show you the changes to that path, even if that file isn't present any more.

You can use the rev-list -n 1 to limit it to the first result returned, which will be the one where it disappeared

git rev-list -n 1 HEAD -- <filename>

That revision is when it disappears, so you can find the parent if you want to restore it with ^ on that revision number

CharlesB
  • 86,532
  • 28
  • 194
  • 218
AlBlue
  • 23,254
  • 14
  • 71
  • 91
  • The same caveat that John Zabroski mentions in the other answer seems to apply here. In fact the latter command only returns the commit where the file was added, even after removing -n 1. – johnny Feb 15 '19 at 08:08
  • Without using the `--full-history` flag, the `git log` output may miss the critical commit – Randall Aug 24 '23 at 17:45