Re: git-pull - strange (copy/rename) messages ?!

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

Linus Torvalds [off-list ref] writes:

quoted

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*