Re: git-mv redux: there must be something else going on

From: Nicolas Pitre <nico@fluxnic.net>
Date: Feb 3, 2010, 20:44 UTC
Message-ID: <alpine.LFD.2.00.1002031533560.1681@xanadu.home>
In-Reply-To: <ron1-34F9C6.12273203022010@news.gmane.org>

On Wed, 3 Feb 2010, Ron Garret wrote:

Show 5 quoted lines

> OK, on closer reading I see that the information is there, but it's well 
> hidden :-)  (For example, the -M option takes an optional numerical 
> argument so you can tweak how much similarity is needed to be considered 
> a move.  But the docs for git log don't mention this.  It's buried deep 
> in the git diffcore docs.  But yes, it's there.)

The doc is indeed not perfect. Probably the -M option and friends could be listed again in the git-log and git-diff pages with a more casual explanation.

Show 5 quoted lines

> So I think I'm beginning to understand how this works, but that leads me 
> to another question: it seems to me that there are potential screw cases 
> for this purely content-based system of tracking files.  For example, 
> suppose I have a directory full of sample config files, all of which are 
> similar to each other.  Will that cause diffcore to get confused?

There are ways to fool the heuristics indeed. But overall it is still more reliable than manually having to record the rename into the tool since humans are known for screwing these things up more often than machines. And again the heuristics can be modified after the fact if needed, unlike the manually recorded false renames (or lack of rename record) which will remain wrong unless another manual correction is applied to the database.

Nicolas