Aidan Van Dyk <aidan@highrise.ca> writes:
>>> It's intentional behavior. �It gives up when there are too many
>>> differences to avoid being slow.
> And, it's configurable, at least to diff and merge. If it's not
> available in all the other porcelains, yes, that would be bugs that
> should be fixed:
FWIW, I was seeing this with git cherry-pick, whose man page gives no
hint of supporting any such option.
> -l<num>
> The -M and -C options require O(n^2) processing time where
> n is the number of potential
> rename/copy targets. This option prevents rename/copy
> detection from running if the number
> of rename/copy targets exceeds the specified number.
Given that we have, in fact, never renamed any files in the history of
the project, I'm wondering exactly why it thinks that the number of
potential rename/copy targets isn't zero. The whole thing smells
broken to me, which is why I am unhappy about the idea of suddenly
starting to depend on it in a big way.
regards, tom lane