Re: git-blame not tracking copies

From: Andy Parkins <andyparkins@gmail.com>
Date: May 3, 2007, 07:29 UTC
Message-ID: <200705030829.31144.andyparkins@gmail.com>
In-Reply-To: <7v8xc64wsu.fsf@assigned-by-dhcp.cox.net>

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.

Show 8 quoted lines

> 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