I won't screened this immediately, as this is a noticeable (and
incompatible) change in the UI.

3 patches for repository http://darcs.net/screened:

patch 6b11cedb1dde629063fc9b21894246734427c67c
Author: Ben Franksen <ben.franksen@online.de>
Date:   Tue Jul 16 21:34:44 CEST 2019
  * resolve issue2550: apply only properly mangled resolutions, warn about any others
  
  To support this change we add the new data type StandardResolution and
  return that from standardResolution. It contains a summary of the data we
  gathered from calling resolveConflicts: the mangled resolutions, merged into
  a single FL, the list of conflicted paths, and an IO action to warn about
  and display any (unravelled) conflicts that we couldn't properly mangle. The
  warning is normally only displayed if we actually want mangling to happen
  i.e. if --mark-conflicts is in effect (except for the mark-conflicts command).

patch ad4467371a96a87438930605e741620f99501001
Author: Ben Franksen <ben.franksen@online.de>
Date:   Tue Jul 16 21:20:52 CEST 2019
  * tests: adapt conflict-doppleganger.sh
  
  A conflict involving 'addfile' prims cannot be cleanly mangled. This means
  that there is nothing to record after the pull and the test therefore fails.
  But this isn't what we want to test, so we record the 'addfile' separately
  and share it.

patch b57365b1d1990d5493086608ef466841e81c4b8f
Author: Ben Franksen <ben.franksen@online.de>
Date:   Tue Jul 16 21:46:45 CEST 2019
  * move announceConflicts from D.R.Merge to D.R.Resolution

Attachments

• patch-preview.txt
• resolve-issue2550_-apply-only-properly-mangled-resolutions_-warn-about-any-others.dpatch
• unnamed

I think the principle is fine, and we need to go in this direction.

I think we should defer the construction of the IO action to the UI
layer. Anything other than the command-line tool will want to 
present the results in a different way and certainly won't want to 
call ePutDocLn.

> I think we should defer the construction of the IO action to the UI
> layer. Anything other than the command-line tool will want to 
> present the results in a different way and certainly won't want to 
> call ePutDocLn.

Right. Will fix.

>> I think we should defer the construction of the IO action to the UI
>> layer. Anything other than the command-line tool will want to 
>> present the results in a different way and certainly won't want to 
>> call ePutDocLn.

Should we return all the raw unravelled conflicts or just those we
couldn't properly mangle?

On 08/08/2019 23:25, Ben Franksen wrote:
> 
> Ben Franksen <ben.franksen@online.de> added the comment:
> 
>>> I think we should defer the construction of the IO action to the UI
>>> layer. Anything other than the command-line tool will want to 
>>> present the results in a different way and certainly won't want to 
>>> call ePutDocLn.
> 
> Should we return all the raw unravelled conflicts or just those we
> couldn't properly mangle?

I guess either return all the raw unravelled conflicts and let the
caller handle mangling what it can and reporting on the rest, or return
the mangled ones + the raw unravelled ones we can't mangle.

> I guess either return all the raw unravelled conflicts and let the
> caller handle mangling what it can and reporting on the rest, or return
> the mangled ones + the raw unravelled ones we can't mangle.

The latter, then. Here we go.

BTW, only the last patch is new, the rest is dependencies.

3 patches for repository http://darcs.net/screened:

patch 6b11cedb1dde629063fc9b21894246734427c67c
Author: Ben Franksen <ben.franksen@online.de>
Date:   Tue Jul 16 21:34:44 CEST 2019
  * resolve issue2550: apply only properly mangled resolutions, warn about any others
  
  To support this change we add the new data type StandardResolution and
  return that from standardResolution. It contains a summary of the data we
  gathered from calling resolveConflicts: the mangled resolutions, merged into
  a single FL, the list of conflicted paths, and an IO action to warn about
  and display any (unravelled) conflicts that we couldn't properly mangle. The
  warning is normally only displayed if we actually want mangling to happen
  i.e. if --mark-conflicts is in effect (except for the mark-conflicts command).

patch b57365b1d1990d5493086608ef466841e81c4b8f
Author: Ben Franksen <ben.franksen@online.de>
Date:   Tue Jul 16 21:46:45 CEST 2019
  * move announceConflicts from D.R.Merge to D.R.Resolution

patch 09bbd7ae6fe2ae2cee8a2e64ce975438a02d1bdd
Author: Ben Franksen <ben.franksen@online.de>
Date:   Fri Aug  9 01:04:08 CEST 2019
  * store the raw unmangled parts of a conflict in StandardResolution
  
  This allows client code to display them in any form they wish, not
  necessarily using ePutDocLn. We do provide warnUnmangled as a convenience
  function, but also showUnmangled and even more low-level showUnravelled.

Attachments

• patch-preview.txt
• resolve-issue2550_-apply-only-properly-mangled-resolutions_-warn-about-any-others.dpatch
• unnamed

>   * resolve issue2550: apply only properly mangled resolutions, warn about any others

Would a test make sense for this new behaviour?

> data StandardResolution prim wX =

This would benefit from some haddocks. Not critical though, it's not too
hard to figure out what's what.

Otherwise fine. Above things are optional so I'll mark this as accepted now.

>   * move announceConflicts from D.R.Merge to D.R.Resolution
>   * store the raw unmangled parts of a conflict in StandardResolution

Fine