title: Why git blame does not follow renames?
body: <pre><code>$ pwd
  /data/mdi2/classes
  
  $ git blame -L22,+1 -- utils.js
  99b7a802 mdi2/utils.js (user 2015-03-26 21:54:57 +0200 22)  #comment
  
  $ git blame -L22,+1 99b7a802^ -- utils.js
  fatal: no such path mdi2/classes/utils.js in 99b7a802^
  </code></pre>
  
  <p>As you have noticed, the file were in different directory in that commit</p>
  
  <pre><code>$ git blame -L22,+1 99b7a802^ -- ../utils.js
  c5105267 (user 2007-04-10 08:00:20 +0000 22)    #comment 2
  </code></pre>
  
  <p>Despite on doc</p>
  
  <pre><code>The origin of lines is automatically followed across whole-file renames (currently there is no option to turn
         the rename-following off)
  </code></pre>
  
  <p>blame does not follow renames. Why?</p>
  
  <p><strong>UPDATE:</strong> Short answer</p>
  
  <p><code>git blame</code> follow renames but not for <code>git blame COMMIT^ -- &lt;filename&gt;</code></p>
  
  <p>But this is too hard to track file renames manually through bulk of renames and ton of history.
  I think, this behaviour must be fixed to silently follow renames for <code>git blame COMMIT^ -- &lt;filename&gt;</code>. Or, at least, <code>--follow</code> must be implemented, so I can: <code>git blame --follow COMMIT^ -- &lt;filename&gt;</code></p>
  
  <p><strong>UPDATE2:</strong> That is impossible. Read below.</p>
  
  <p><strong>ANSWER FROM MAILLIST</strong> by Junio C Hamano </p>
  
  <blockquote>
    <p><code>git blame</code> follow renames but not for <code>git blame COMMIT^ -- &lt;filename&gt;</code></p>
  </blockquote>
  
  <p>Suppose you have file A and file B in your version v1.0.</p>
  
  <p>Six month down the road, the code was much refactored, and you do
  not need the contents of these two files separately.  You have
  removed A and B and much of what they had is now in file C.  That is
  the current state.</p>
  
  <pre><code>git blame -C HEAD -- C
  </code></pre>
  
  <p>may follow the contents from both just fine, but if you <em>were</em>
  allowed to say</p>
  
  <pre><code>git blame v1.0 -- C
  </code></pre>
  
  <p>what does it even mean?  C did not exist v1.0 at all.  Are you
  asking to follow the contents of A back then, or B?  How did you
  tell you meant A and not B when you told it C in this command?</p>
  
  <p>"git blame" follows content movements, and never treats "renames" in
  any special way, as it is a stupid thing to do to think a rename is
  somehow special ;-)</p>
  
  <p>The way you tell what content to start digging from to the command
  from its command line is to give starting point commit (defaults to
  HEAD but you may give COMMIT^ as your example) and the path in that
  starting point.  As it does not make any sense to tell C to Git and
  then magically make it guess you meant A in some cases and B in some
  other.  If v1.0 did not have C, the only sensible thing to do is to
  exit instead of making a guess (and without telling the user how it
  guessed).</p>