On Mon, Feb 28, 2011 at 02:05:37PM +0100, Michael J Gruber wrote: > When I said "copy patch" I actually meant a patch which records the copy > "Makefile -> Dofile". What is it today? Is it me? I know I wrote the > "mv" example first, but still :) Yeah, I looked at the "mv" example and totally glossed over the word "copy" in your text. > I mean, Alice: > cp Makefile Dofile > sends me a -C patch > > I: > Break everything by hacking Makefile > send her a crappy patch > > Both: > apply the received patch > > Now I end up with a borked Makefile and a borked Dofile, but Alice still > has a good Dofile, and it's all my fault, so I don't deserve any better. > But still. OK, this is a much better example. Yes, you have different state at the end, and there were no conflicts. I don't think we can resolve the situation automagically, but I think it would at least be nice to mention the conflict. I guess the big question is how to mention it. Should it cause the patch application to fail? I'm worried about that creating unnecessary false positives for cases that are really quite harmless. Should patch application just give a warning unless --strict-renames or something is used? I dunno. This is one of those corner cases where we can see that there is a potential problem, but it hasn't actually come up in practice, so it's difficult to see what would be most useful in the real world. Maybe that means we are wasting our time thinking about it. :) > This is orthogonal to the "-D" suggestion", but "-D" could write the > index line to start with. Yeah. I had just assumed that "-D" would be the same as the current text, minus the actual patch lines. IOW: diff --git a/Makefile b/Makefile deleted file mode 100644 index c9ff69c..0000000 -Peff -- 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