We have discussed this change on the list. I think this is the only viable
solution we can currently implement without a change in the semantics of
prim patches. It also lines up with (and gives an official justification
for) not looking beyond the latest clean tag when searching for conflicts
(see patchsetConflictResolutions).

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

patch 6f7195b9d5fd43169850bc85f2ebd28bbd52abb9
Author: Ben Franksen <ben.franksen@online.de>
Date:   Sat Jul 20 13:51:58 CEST 2019
  * regard explicit dependencies as resolving conflicts
  
  This is necessary to allow users to resolve a conlfict in favour of what
  darcs does by default (i.e. apply neither of the conflicting changes). The
  implementation is mostly in Darcs.Patch.Named which now has an instance
  Conflict. The PatchInfoAnd instance only delegates to the contained Named 
  patch. A subtlety here is that for efficiency and correctness in the face of
  lazy repos, we must make sure that hopefully is lazy in its patch argument.

Attachments

• patch-preview.txt
• regard-explicit-dependencies-as-resolving-conflicts.dpatch
• unnamed

Would you mind adding a comment to the Conflict (Named p) instance to
explain the rationale for the behaviour?

Otherwise looks fine.

> Would you mind adding a comment to the Conflict (Named p) instance to
> explain the rationale for the behaviour?

Good idea. I just started to write down a description and justification.
This made me see a flaw in the algorithm, which I think can lead to an
unresolved conflict not being shown because it erroneously regards it as
resolved. Can you spot the problem?

I am still thinking about how to fix it...

Cheers
Ben

> This made me see a flaw in the algorithm, which I think can lead to an
> unresolved conflict not being shown because it erroneously regards it as
> resolved. Can you spot the problem?

Is it to do with the fact that even content-based dependencies at the
Named level are less fine-grained than at the level of the contents of
those Nameds, since a Named contains an FL? So if p depends on q by
name, q depends on r by content, then r will end up in ctx. But if some
element of r that *isn't* depended on by something in q has a conflict,
we should perhaps regard it as unresolved.

>> This made me see a flaw in the algorithm, which I think can lead to an
>> unresolved conflict not being shown because it erroneously regards it as
>> resolved. Can you spot the problem?
> 
> Is it to do with the fact that even content-based dependencies at the
> Named level are less fine-grained than at the level of the contents of
> those Nameds, since a Named contains an FL? So if p depends on q by
> name, q depends on r by content, then r will end up in ctx. But if some
> element of r that *isn't* depended on by something in q has a conflict,
> we should perhaps regard it as unresolved.

Exactly. So if A1 and A2 are unrelated conflicted changes, B1 depends on
A1, but not A2, we have named patches A=(A1;A2) and B=(B1) and finally C
which depends on B by name. Then even A2 will count as resolved, which I
think is wrong.

The difficulty in fixing this is that we now need a way to pass the
information about which patches we /do/ know are resolved (all those
which are directly depended on by name) down to the resolveConflicts of
the lower layer. I think this requires another change to the API.

Or we pursue the idea of Dependors that capture explicit dependencies at
the RepoPatch level (that wouldn't work for V1 and V2, but perhaps this
is okay).

As discussed, the algorithm used before was too simple: it could lead to
conflicts being hidden by indirect dependencies between Named patches. It
turned out that this can be fixed without changing the API.

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

patch 7ae6089abf4eee4b583a9f9724bb49d90def4e28
Author: Ben Franksen <ben.franksen@online.de>
Date:   Sat Aug 31 17:26:55 CEST 2019
  * fix and document instance Conflict Named

Attachments

• fix-and-document-instance-conflict-named.dpatch
• patch-preview.txt
• unnamed

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

patch 3ee34d503c4a79de22531f261fa251e700d87c2a
Author: Ben Franksen <ben.franksen@online.de>
Date:   Sun Sep 15 12:17:52 CEST 2019
  * extend tests/resolve-conflicts-explicitly.sh
  
  This adds a test that explicitly depending on a partial resolution does not
  inadvertantly turn it into a full resolution. It also cleans up the existing
  test with better names for the patches and defines a common baseline for the
  conflicts.

Attachments

• extend-tests_resolve_conflicts_explicitly_sh.dpatch
• patch-preview.txt
• unnamed

This is the last bundle that still stands in the way of pulling the
2.15.1 tag to reviewed, so if you could finish the review this would
make it easier for me to catch up with reviewing your patches in turn...

It really was a bad idea to tag screened. We should never do that again.
And we should make a 2.15.2 tag that includes all the follow-up patches,
this time directly on the reviewed repo.

Looks ok. The whole setup is now complicated enough that I can't completely
convince myself it's right. But I certainly can't spot any problems and the
overall situation seems better than before this patch.

I'll run the tests and push all the 'accepted-pending-tests' patches to 
reviewed now.