Git - why are double dashes needed when running a command on a deleted file?

Question

Consider a git repository, where a file was once deleted.

git rm path/to/file
git commit -a -m\"testing\"

Ok, now I want to see the g

Answer 1

Why the difference when the file exists versus when it doesn't? Let's look at the cases:

1. A revision and filename both exist. Obviously ambiguous.
2. A revision exists and filename doesn't. Obviously not ambiguous.
3. A revision doesn't exist and a filename does. Obviously not ambiguous.
4. A revision doesn't exist and a filename doesn't either. Ambiguous?

Indeed it is.

To know whether a file ever existed at some path means to walk history, opening each commit, opening each tree and walking the tree to see if this path existed then. On a large repository with a lot of commits and a deep path... this could get expensive, especially on a slow disk.

But! You say. Isn't that exactly what git log filename does anyway? And the answer is yes, it is. The difference is that when I run git log filename and the file is known to exist, then git-log knows that I want to spend the time to get this history.

If, instead, I run git log foo and foo is not a revision or a file that currently exists then it would need to invest the time to walk the entire graph just to tell me that foo was ambiguous.

Ouch.

So you're welcome to say git log -- filename to tell git that you really want it to go walking the graph. Otherwise, it will decline.

Side note: git merely stat(2)s the argument you give on the command line to determine if the file exists. It doesn't look in the index, nor does it open up your HEAD tree. It could, of course, do those things, which would allow you to use git log filename where filename was a deletion not staged for commit. This seems like a very reasonable change.