title: Git - why are double dashes needed when running a command on a deleted file?
body: <p>Consider a git repository, where a file was once deleted.</p>
  
  <pre><code>git rm path/to/file
  git commit -a -m"testing"
  </code></pre>
  
  <p>Ok, now I want to see the <code>git log</code> for the file, but I receive the classic error message:</p>
  
  <pre><code>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
  </code></pre>
  
  <p>The solution is simple - add <code>--</code>:</p>
  
  <pre><code>git log -- path/to/file
  </code></pre>
  
  <p>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.</p>
  
  <p>On the other hand, it's possible to have a tag named the same as a file, which <code>git log</code> handles pretty well:</p>
  
  <pre><code>fatal: ambiguous argument 'path/to/file': both revision and filename
  Use '--' to separate filenames from revisions
  </code></pre>
  
  <p>This behavior seems inconsistent. Could anyone explain what the developers of git had in mind?</p>