On Mon, 30 Aug 2010, Tim Mazid wrote:
> Matthieu Moy wrote:
> > 2. I am mystified not by some particular piece of code but by an
> > entire file. The command
> > $ git gui blame -- git.c
> > works okay.
>
> It does, to an extent.
>
> The specific case I was thinking of is when, as a function grows
> larger, you decide to break it down and move a section of it to a new
> function. Now, if the two lines remain exactly the same, there is no
> problem and git gui blame does the job.
>
> However, if there is any change in the line at all, even leading
> whitespace, as moving code around usually changes its "tabbage", then
> "git gui blame" will not detect that as being the same line of code
> sitting somewhere else, as it sees the two as "different".
> Is there any way to get around this?
>
> Further, in the previous point regarding a movement patch, it too
> should not be overly sensitive to leading whitespace.
>
> Actually, git in general shouldn't be too sensitive to leading
> whitespace (or at least should have an option to turn this on/off).
You can always pass `-w' option to git-blame:
-w Ignore whitespace when comparing the parent's version and the
child's to find where the lines came from.
I'm not sure if you can pass other diff whitespace options to git-blame
(-b, -w, --ignore-space-at-eol).
Note that "git gui blame" shows *two* blames: ordinary and '-C -C -w',
i.e. with copy detection and ignoring whitespace changes.
--
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