From: Daniel Barkalow <barkalow@iabervon.org>
Date: Tue, 01 Nov 2005 22:03:26 GMT
Subject: Re: git-pull - strange (copy/rename) messages ?!
Message-ID: <Pine.LNX.4.64.0511011646070.25300@iabervon.org>
In-Reply-To: <7vbr149sbs.fsf@assigned-by-dhcp.cox.net>

On Tue, 1 Nov 2005, Junio C Hamano wrote:

> Linus Torvalds <torvalds@osdl.org> writes:
> 
> > Btw, Junio, I thought "git pull" was only supposed to do rename 
> > detection, not copy detection.
> 
> Sorry, but what do you mean by "only rename detection but not
> copy detection" in this case?
> 
> When you have "ce A B; ce A C; ce A D;... ; mv A Z", (ce is like
> cp but "copy+edit") where B-Z are all new files and A disappears
> from the result, trying to detect renames would end up detecting
> copies without extra processing; B through Z are rename
> destination candidates, and A is a rename source candidate
> (there may be others), and it turns out that B-Z all look like
> A.
> 
> Would it be easier to read if we say A was renamed to B, and A
> was renamed to C, and A was renamed to D, ...?  I think the
> current output is easier to understand than that.  B-Y gets
> labelled as copy of A and Z gets labelled as rename.

I think it's more confusing for the system to report Z differently from 
other things, because there's nothing special about what it found, except 
that Z happens to be last. I think it would be easiest to read as:

Rename A =>
  B (80%)
  C (85%)
  D (75%)
  ...
  Z (90%)

(Although I don't know if the results come out of the system sorted that 
way; obviously, if there are different removed things, mixing them 
together would be ambiguous in this format)

	-Daniel
*This .sig left intentionally blank*