Git - why are double dashes needed when running a command on a deleted file?
git, git-log
Solution
`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.
Problem
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?