git log - 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 git log for the file, but I receive the classic error message:

git log path/to/file
fatal: ambiguous argument 'path/to/file': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions

The solution is simple - add --:

git log -- path/to/file

But... why? Why is this needed? What is the rationale here? Can't git do an educated guess, that this might have been a file once? I understand the "ambiguity" problem - but there never was a tag by that name. If the file was once deleted, and no tag is present, then choosing "the file interpretation" is always the good choice.

On the other hand, it's possible to have a tag named the same as a file, which git log handles pretty well:

fatal: ambiguous argument 'path/to/file': both revision and filename
Use '--' to separate filenames from revisions

This behavior seems inconsistent. Could anyone explain what the developers of git had in mind?

Answer 1

git log could be used on files as well as on branches, tags and so on.

Assume you have a folder called a/b/c, you'll get the commits for this folder using

git log a/b/c

That's fine.

You could also have a branch called d/e/f. You'll get the commits for this branch using

git log d/e/f

That's fine too.

Things start to get complicated if the item where git log should work on could not be clearly determined. If you're stupid and call your branch a/b/c too, git has no clue whose log shall be printed: that of the branch a/b/c or the log of your directory a/b/c? Therefore, you have to tell a bit more about the information you want to receive:

• show the log of the branch a/b/c:
  git log a/b/c --
• show the log of the folder a/b/c in the current branch:
  git log -- a/b/c
• show the log of the folder a/b/c in the a/b/c branch:
  git log a/b/c -- a/b/c

With the deleted file, you have a similar problem: there's neither a file called path/to/file present in the working copy, nor is there a branch called path/to/file. This is the reason why you have to specify what you want.

Of course, git could know that there was a file called path/to/file 20.000 revisions ago but this would require (worst case) to search the entire history of your project whether such a file existed or not.

By explicitly specifying the file path after the --, you tell git:

search harder for that file, even if it takes hours

---

Conclusion (answering your question):
in your case, the -- is needed because otherwise git log would work slower in general.