1 patch for repository http://darcs.net/screened:
Author: Ben Franksen <email@example.com>
Date: Mon Jun 4 17:49:21 CEST 2018
* in D.R.Resolution, throw an error if cleanly merging conflict
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
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.