darcs

Patch 1709 throw an error if cleanly merging conflict resolutions fails

Title throw an error if cleanly merging conflict resolutions fails
Superseder Nosy List bf
Related Issues
Status review-in-progress Assigned To
Milestone

Created on 2018-07-18.17:43:43 by bf, last changed 2018-08-08.09:38:42 by bf.

Files
File name Status Uploaded Type Edit Remove
in-d_r_resolution_-throw-an-error-if-cleanly-merging-conflict-resolutions-fails.dpatch ganesh, 2018-07-22.23:36:32 application/octet-stream
See mailing list archives for discussion on individual patches.
Messages
msg20205 (view) Author: bf Date: 2018-07-18.17:43:43
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.
msg20223 (view) Author: ganesh Date: 2018-07-22.23:36:32
Actually attaching this patch too :-)
Attachments
msg20235 (view) Author: ganesh Date: 2018-07-31.06:33:41
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.
msg20237 (view) Author: bf Date: 2018-08-08.09:38:41
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.
History
Date User Action Args
2018-07-18 17:43:43bfcreate
2018-07-18 17:44:22bfsetstatus: needs-screening -> needs-review
2018-07-22 23:36:32ganeshsetfiles: + in-d_r_resolution_-throw-an-error-if-cleanly-merging-conflict-resolutions-fails.dpatch
messages: + msg20223
2018-07-31 06:33:42ganeshsetstatus: needs-review -> review-in-progress
messages: + msg20235
2018-08-08 09:38:42bfsetmessages: + msg20237