Re: git blame --follow

From: Jakub Narebski <jnareb@gmail.com>
Date: Mar 17, 2011, 09:59 UTC
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