Wolfgang Rohdewald <wolfgang@xxxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html