nasty bug when applying patches
Dominik Psenner
dpsenner at gmail.com
Thu Apr 5 13:16:19 UTC 2012
>> Could this bug be a duplicate of 1175?
>
>No this is a brand new bug:
>
> http://mercurial.selenic.com/bts/issue3357
>
>I am not sure which part is misbehaving yet. Thank you for reporting it.
You don't have to thank me for that. I had to apply around 450 hunks across
50 files or so manually. That took me about 3 hours so that I found it
rather important to be reported. :-)
Anyway, I tried an older 1.7.5 mercurial and the same thing happened there.
It feels strange that noone ran into this bug for so long?
So far I observed that given the patch:
# HG changeset patch
# User test
# Date 0 0
# Node ID d9adadb0607aa6f297ed276355f02bbbac150078
# Parent b223f2abdff27a2eeedefd683322f9533a0186c6
1
diff --git a/d/f b/d 2/f
rename from d/f
rename to d 2/f
--- a/d/f
+++ b/d 2/f
@@ -1,1 +1,2 @@
f
+f
applying the patch does first a rename from 'd/f' to 'd 2/f' and then tries
to apply the hunks to 'd/f' which is no longer there. Obviously it fails and
tries to save the rejects to 'd/f.rej'. Since that files doesn't exist
either, it saves the rejects to 'd.rej'. Which by the way is overridden by
other failing hunks if other files were moved from 'd/' to 'd 2/' too.
Thanks for looking into this!
Cheers,
Dominik
More information about the Mercurial-devel
mailing list