nasty bug when applying patches

Dominik Psenner dpsenner at gmail.com
Thu Apr 5 08:16:19 CDT 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