darcs

Issue 2550 conflict resolution for non-hunks is rotten

Title conflict resolution for non-hunks is rotten
Priority Status unknown
Milestone Resolved in
Superseder Nosy List bf
Assigned To
Topics

Created on 2017-09-22.15:37:29 by bf, last changed 2018-04-24.18:04:22 by bf.

Messages
msg19663 (view) Author: bf Date: 2017-09-22.15:37:28
What I mean is the standard resolution as implemented in
Darcs.Patch.Conflict.mangleUnravelled: unless the input consists only of
hunks, it simply takes the head of the list. In other words: pick any
version, whatever comes first.

You can see that when you pull 'addfile ./x' into a repo with 'adddir
./x' (see issue2548 for what else goes wrong when you do that) using
--mark-conflicts: for darcs1 it gives you the directory x, for darcs2 it
gives you the file x. Neither is a good solution: it should instead
produce the equivalent of the usual "conflict markup" in the file
system. That is:

The standard conflict resolution for name collisions (add or move with
the same target path) should be (pending) moves for *both* to some not
yet existing name. For instance, if the target is "./path/to/thing",
then I would like to get ./path/to/thing.~1~ and ./path/to/thing.~2~ so
I can properly compare the two and chose one or create a mixture of both.

(Ideally, instead of increasing numbers, we should append the hash,
perhaps suitably shortened, of the named patches that contain the
conflicting prims. This is a different issue, however, as it pertains to
hunk conflicts in very much the same way.)
msg20119 (view) Author: bf Date: 2018-04-19.06:41:09
This is probably best deferred until we have a new patch format (with
camp-style conflictors); the calculation of conflict resolution markup
is pretty messy and we probably have to re-write it anyway.
msg20125 (view) Author: gh Date: 2018-04-22.23:21:09
Maybe the situation described in the first message is a consequence of
the fact that Darcs captures and expresses conflicts only as
modifications of the working tree.

It Darcs had another place to put this data, say some file
_darcs/conflicts , and a more interactive and detailed UI for whatsnew
in case of conflicts and mark-conflicts, we probably would be able to
give to the user the complete explanation of what conflicts are
currently happening in their repo.
msg20128 (view) Author: bf Date: 2018-04-24.18:04:21
Yes, an extra file with detailed explanations about conflicts would be a
good addition. Needs a bit more detail (file format, syntax).
 
I still like the idea of getting "markup" in the working tree itself,
i.e. rename both to new versions inside the tree, with some special suffix.

We can do both, of course.
History
Date User Action Args
2017-09-22 15:37:29bfcreate
2018-04-19 06:41:10bfsetmessages: + msg20119
2018-04-22 23:21:11ghsetmessages: + msg20125
2018-04-24 18:04:22bfsetmessages: + msg20128