Dnia czwartek 17. marca 2011 11:16, Wolfgang Rohdewald napisaÅ:
> On Donnerstag 17 MÃrz 2011, Jakub Narebski wrote:
> > So you probably want to run "git blame -C -C <file>", not "git
> > blame <file>".
>
> that does the trick - I only tried "git blame -C"
Hmmm... it is described in git-blame(1) manpage, but you have to read
it carefully.
"git blame" synopsis states:
'git blame' [-c] [-b] [-l] [--root] [-t] [-f] [-n] [-s] [-e] [-p] [-w] [--incremental] [-L n,m]
[-S <revs-file>] [-M] [-C] [-C] [-C] [--since=<date>]
[<rev> | --contents <file> | --reverse <rev>] [--] <file>
The important thing is to notice '[-C] [-C] [-C]' here.
In the description of '-C' option we have:
-C|<num>|::
In addition to `-M`, detect lines moved or copied from other
files that were modified in the same commit. This is
useful when you reorganize your program and move code
around across files. When this option is given twice,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
the command additionally looks for copies from other
files in the commit that creates the file. When this
option is given three times, the command additionally
looks for copies from other files in any commit.
I have underlined important part.
--
Jakub Narebski
Poland
--
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