1 patch for repository http://darcs.net/screened:

patch 7729f69479ed36a1733f5be67721a8c0ddfd6e51
Author: Ben Franksen <ben.franksen@online.de>
Date:   Mon Jun  4 17:49:21 CEST 2018
  * in D.R.Resolution, throw an error if cleanly merging conflict
resolutions fails
  
  This is clearly an internal error and should be handled as such. It was
  previously ignored by silently dropping the patch that could not be
merged.

Actually attaching this patch too :-)

Attachments

• in-d_r_resolution_-throw-an-error-if-cleanly-merging-conflict-resolutions-fails.dpatch

Are you actually sure this can't happen, or just want to make sure
we find out about any instances where it does happen? Either way 
some explanation in the comment of the reasoning would help.

I never intuitively understand what 'resolveConflicts' is actually 
expected to produce. From quick look at the code, which returns a 
nested list, I think the outer layer has one element per conflict. 
For each conflict, if it is an all-hunk conflict, then the inner 
layer is the marked-up conflict followed by the individual 
conflicting options. If it's not all-hunk then the inner layer is 
just the first of the conflicting options followed by all the 
conflicting options. In fact, looking at the uses, I think we always 
only take the first option from the inner lists, so maybe we can
simplify the method.

It really should not happen. If it does than we have a bug and we want
to know about that.

And yes, I think you are right with the inner and outer layers. I think
the idea was to have an API that works for a single patch as well as for
a list of patches (e.g. a full repo). This obscures things and I am all
for turning it into a single layer and abandon the instance for patch
lists. This is going to be a rather difficult refactor, though.

I've added an explicit type for the inner list in patch1806, which
makes the distinction clearer. I don't have much idea about what could
be done about the outer list yet.