Hi Jon,
Which failure mode? I missed the description of a failure anywhere in this discussion. Is there a repeatable bug setup that duplicates this failure?
Yes indeed, it seems you missed the description, although I clearly cited it now multiple times:
This option you used to make the patches smaller (find-copies or something like this) really makes reviewing not easy. And additionally the patch doesn't apply anymore, since the reference
^^^^^^^^^^^^^^^^^^^^^^^^^^^
(sequoia) has changed in my non publiched branch already. Another reason why I would like to see a 100k size limit on this list.
Are you just referring to it not finding copies in patches by default? And that in this case someone used them to make the patch smaller? I mean, if it says 100% copy, then it is a literal move, and if it is fractional, the relevant diffs should be present in the patch still anyway.
No, I was talking about a diff based on the "copy and change" variant not working anymore after the origin of the copy is changed _in the repository where git-apply is attempted_.
Right. As long as the SHA1 in the patch are present in the repository to which the patch is being applied, it will attempt to revert to a 3-way merge based on that ancestor.
Exactly, this was my original point. I obviously failed to make it clear that git-apply or git-am alone will fail under the above conditions.
For the git savvy among the readers on a lower level this uses "--build-fake-ancestor" from git-apply although this option does not lend itself to easy usage from a command line.
Uh, "-3" on a "git am" command is pretty easy, isn't it? :-)
Did I say anything different? It was just an interesting piece of information that I discovered in the process that I didn't want to keep for myself.
Which might be a subtle way of saying that I missed your point, perhaps?
So it seems.
Cheers Detlev