I have a combination of a GHC tree and a patch bundle that displays the
following behaviour:

~/darcs/ghc-bug > darcs w -s              
No changes!
zsh: 5434 exit 1     darcs w -s
~/darcs/ghc-bug > darcs apply ~/bug.patch 
Finished applying...
~/darcs/ghc-bug > darcs w -s             
 ./compiler/cmm/CmmBrokenBlock.hs -> ./compiler/cmm/CmmCPSData.hs
A ./compiler/cmm/CmmBrokenBlock.hs
R ./compiler/cmm/CmmCPSData.hs

That is, apply the bundle leaves my working copy with changes in it.  There are
no conflicts.

The patch bundle has two patches in it; applying the patches separately avoids
the bug.  It looks like something related to renaming files: one of the patches
has a rename + some changes to the same file.

I've attached the patch bundle, and I'll attach the GHC tree for reproducing the
bug separately.

Attachments

• bug.patch

Here's the GHC tree.

Forgot to mention: darcs version 1.0.9, on x86_64-Linux.  Also I should say that
this isn't restricted to apply: pulling the patches from another repo displays
the same behaviour, but you have to pull the two patches together.

Attachments

• ghc-bug-repo.tar.bz2

Any ideas, David?  This one looks kind of interesting.  It would be great if we
could boil it down to a minimal test case.

To simplify, first patch adds f1; second patch moves
  f1 -> f2
and modifies f2

And whatsnew shows
  f2 -> f1 (inverse)
  A f2
  R f1

As though Simon had rollback'ed the move and then done it over by hand.

Interestingly, I can't reproduce it with Simon's tarball/patch combo (applies
cleanly), but this is on MacOS X and with darcs 1.0.8.  Will have to check later
if I get the same thing on 1.0.9.  No conflicts or anything weird, as far as I
can see.

Just for info, I can reproduce this with both 1.0.9 and 1.1.0 (unstable) under
Linux (32 bit).

Sounds pretty serious (and sounds like a regression).  Would be nice if we had a
small test case.

Ok, now we have a minimal test case!  (Submitted as a patch to darcs-devel). 
Note that (bizarrely enough), the second filename must start with an uppercase
character for the bad things to happen.

mkdir temp1
cd temp1
darcs init
echo abc > a
darcs add a
darcs record --all -m patch1 -A moi
darcs mv a B
echo def > B
darcs record --all -m patch2 -A moi
cd ..

mkdir temp2
cd temp2
darcs init
darcs pull --all ../temp1
darcs whatsnew | grep 'No changes'

It seems to be the pending patch that haunts us again. A simple
rm _darcs/patches/pending clears the problem.

By the way, the pending file seems to be "correct" in some way,
because a Record (even with extra "real" changes) produces a
valid repo, although with a very strange looking patch.

Based on Ian's comment on IRC, here is a simplified version of the test.
Capitalisation is not the issue; sorting is.

mkdir temp1
cd temp1
darcs init
echo abc > b
darcs add b
darcs record --all -m patch1 -A moi
darcs mv b a
echo def > a
darcs record --all -m patch2 -A moi
cd ..

mkdir temp2
cd temp2
darcs init
darcs pull --all ../temp1
darcs whatsnew | grep 'No changes'

Resolved in unstable with David's serendipitous patch:

Wed Aug  8 02:52:51 CEST 2007  David Roundy <droundy@darcs.net>
  * fix bug that revealed itself in optimize --reorder on unstable repo.