Re: git-blame not tracking copies

[Andy Parkins <andyparkins@gmail.com>]

On Thursday 2007 May 03, Junio C Hamano wrote:

> I am sick and not functioning well today, so will not be able to

I'm sorry to hear that.  I hope you feel better soon.

> review what is happening with your example deeply, but here are
> some comments to get you started digging.
>
> There is a built-in sanity valve in git-blame that refuses to
> pass down the blame via -M/-C for really trivial hunks.  Without
> such safety, all the empty lines in the latest revision would be
> attributed to a random empty line in a random file in the root
> commit ;-).

That sounds like an excellent feature.  However - in the case of a full 
file-to-file copy, surely that valve may be safely disabled for that one 
step?

The copy is easily detectable because the hash is the same, so can't git-blame 
just continue having flipped itself on to the original filename?  I suppose 
in essence a move is the same, the only difference between a move and a copy 
is that in one case the copy is spatial in the other it is temporal.

Please excuse the fact that in the above I've completely minimised the fact 
the job git-blame does is flippin' hard; I don't mean to imply that "any fule 
could fix it" - because I can't :-)



Andy

-- 
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com