Re: limiting rename detection during merge is a really bad idea

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Feb 11, 2008, at 12:20 PM, Santi Béjar wrote:

Steffen, can you tell us how large your rename set is (unfortunately,
there is no way to get this information easily; you can stop
merge-recursive in the debugger at diffcore-rename.c:457 and look at
num_src and num_create). And how long it takes to run with
diff.renamelimit turned off?

I don't know the size.  I can only say that it took a few
seconds on a MacBook Pro.


That might give us a clue where a reasonable value is.

Additionally git could warn if the limit is reached in the merge.

I think this would have saved me.  I did not know about the
rename limit.  Therefore I did not understand why the merge
failed.  If git merge had reported that the rename detection
limit was reached, I probably would have looked up what this
limit is about.  At least git should tell when rename detection
gets disabled.  Users expect that renames work and git should tell
the user when it does not even try to detect renames.

Personally, I can easily switch to a larger machine if this
helps completing a merge and I think I would do this.  But
I also know that I shouldn't expect too much from a larger
machine for an O(n^2) algorithm.

	Steffen
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux