From: Jakub Narebski <jnareb@gmail.com>
Date: Thu, 17 Mar 2011 09:59:22 GMT
Subject: Re: git blame --follow
Message-ID: <m3tyf25arl.fsf@localhost.localdomain>
In-Reply-To: <201103151926.58449.wolfgang@rohdewald.de>

Wolfgang Rohdewald <wolfgang@rohdewald.de> writes:

> But with my repository (which I cannot share),
> this does not happen. git blame attributes everything to 
> the renaming commit. If I checkout the commit before, git
> blame shows everything correctly.

"git blame" manpage says:

       -M|<num>|
              Detect  moved  or copied lines within a file. [...]
              [...]
              <num> is optional [...]

       -C|<num>|
              In  addition  to  -M,  detect lines moved or copied from other files
              that were modified in the same commit.

Sidenote: I wonder why we use '-M|<num>|' and not '-M[<num>]' here.

So you probably want to run "git blame -C -C <file>", not "git blame <file>".
Note that it is the same option name to turn on rename detection as is
used for for "git diff".

Note that "git gui blame" shows _two_ commits for each line: one is
result of "git blame" (and it would show commit that did code
movement, or renamed file), the other is result of "git blame -C -C -w",
which would show commit that changed line, disregarding whitespace-only
change (like e.g. reindent caused by extracting code into separate
function).

I wonder if it would be possible to generate result of "git blame"
and of "git blame -C -C -w" in a single run (with --porcelain or
--incremental)...

[...]
> And - for directories below the renamed one git log --follow 
> cannot cross this barrier either but if the "follow" logic
> is different I suppose this is not related

The implementation of "git log --follow <file>" is a bolted-on hack,
and it doesn't work in all cases; for example it doesn't cross
boundaries of subtree merge, IIRC.  Try "git log --follow gitweb/gitweb.perl"
in git repository itself...

HTH
-- 
Jakub Narebski
Poland
ShadeHawk on #git