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