I was trying to review patch530 when I ran into this problem.  I wonder 
if the use of ask-deps is related.

I think the basic recipe is (see file2257)

darcs get http://darcs.net/screened --lazy --context ignoring-
applytoworking-return-value-is-safe.dpatch
cd screened
darcs apply ../applytoworking-return-value-is-safe.dpatch
cd ..
darcs get http://darcs.net unstable --lazy
cd unstable
darcs pull -a ../screened -p "Ignoring applyToWorking return value is 
safe"
darcs pull -a ../screened -p "Remove redundant Packs and NoPacks"

The result of this is
darcs: bug at src/Darcs/Patch/Depends.hs:208 compiled Jan  5 2011 
17:44:09
Failed to commute common patches:
Tue Jan 18 09:36:54 GMT 2011  Gabriel Kerneis <kerneis@pps.jussieu.fr>
  * Ignoring applyToWorking return value is safe
  
  See issue1988.
Fri Jan 14 15:44:49 GMT 2011  Florent Becker <florent.becker@ens-
lyon.org>
  * add a --no-record option to rollback
Tue Nov 23 07:42:43 GMT 2010  Ganesh Sittampalam <ganesh@earth.li>
  * abstract Prim behind a class
Sun Nov 21 17:01:27 GMT 2010  Ganesh Sittampalam <ganesh@earth.li>
  * resolve more conflicts with issue332 patch
See http://wiki.darcs.net/BugTracker/Reporting for help on bug 
reporting.

What we need now is to turn this into some kind of minimal test case. 

Note that darcs-2.4 reports this as a bug in get_extra (so we're making 
UI progress at least!)

Here's a context file for unstable so we can reproduce this more easily 
in the future.

Attachments

• issue2036-unstable-context

But the following works:

darcs get http://darcs.net/screened --lazy --context
issue2036-unstable-context
darcs  get http://darcs.net unstable --lazy
cd unstable
darcs pull -a ../screened
# 92 patches to pull, do you really want them all?
cd ../screened
darcs apply ./applytoworking-return-value-is-safe.dpatch
cd ../unstable
darcs pull -a

No idea what this means.

Also note that I can reproduce the bug even if I re-record the patch
without ask-deps, so it has nothing to do with it.

Even stranger, if you follow exactly the same procedure, but pull the
patches in reverse order, it works too:

darcs get http://darcs.net/screened --lazy --context ignoring-
applytoworking-return-value-is-safe.dpatch
cd screened
darcs apply ../applytoworking-return-value-is-safe.dpatch
cd ..
darcs get http://darcs.net unstable --lazy
cd unstable
darcs pull -a ../screened -p "Remove redundant Packs and NoPacks"
darcs pull -a ../screened -p "Ignoring applyToWorking return value is safe"

Applying the patches in the reverse order does seem to work.  We still 
need to debug this, but at least we aren't blocked on applying patch530

I have another example of this, if needed - a patch just recorded against 
the hledger repo (with darcs 2.4.4) triggers this error when applied (with 
all darcs versions).

At its core this is most probably a duplicate of issue1327 which is
about the broken darcs patch theory. In short: whether a commute of
three or more patches succeeds or fails may depend on the order in which
we try it.