[darcs-devel] Addressing "darcs rebase --unsuspend should stop at first conflict"

Dan wilsonhardrock at gmail.com
Wed Dec 27 16:13:11 UTC 2017


I'm interested in addressing this ticket http://bugs.darcs.net/issue2552
"darcs rebase --unsuspend should stop at first conflict". I've done a bit
of research into the codebase and am looking for verification of my
understanding and tips on further approaches.

So far, I've been digging around in the unsuspendCmd function in
Darcs.UI.Commands.Rebase. On line 373, there is this section:

    have_conflicts <- announceMergeConflicts "unsuspend"
        (allowConflicts opts) (externalMerge ? opts) standard_resolved_p
    Sealed (resolved_p  :: FL (PrimOf p) wA wB) <-
        case (externalMerge ? opts, have_conflicts) of
            (NoExternalMerge, _) ->
                case O.conflictsYes ? opts of
                    Just O.YesAllowConflicts -> return $ seal NilFL -- i.e.
don't mark them
                    _ -> return $ seal standard_resolved_p
            (_, False) -> return $ seal standard_resolved_p
            (YesExternalMerge _, True) ->
                error "external resolution for unsuspend not implemented
yet"

I think at that point we know about any conflicts. Additionally from my
reading it appears that the externalMerge resolution strategy is capable of
pausing at conflicting patches while it calls an external merge tool to
handle the conflicts. This isn't currently implemented for unsuspend, but
appears to implemented for other commands using applyPatches by way of
standardApplyPatches by way of tentativelyMergePatches.

It looks like the doAdd helper function is responsible for actually adding
the unsuspended patches to the repository, although it doesn't seem to do
anything specific to patches with conflicts.

For an approach, I'm thinking of two things (in no particular order):

1. I can try to implement the external merge tool option for rebase
unsuspend and work its method of pausing at conflicts into the internal
merge tool logic.
2. I can try adding some specific logic to check if a patch being added in
"doAdd" has conflicts and pause there to allow users to fix the conflicts.

As considerations for how this should work. If I was using this, I think I
would like to be able to handle conflicts in one of two ways. The first way
would be to resolve the conflicts and amend them into the patch being
unsuspended. The second way would be to resolve the conflicts and work them
into one (or more) new patches. I think a solution should include these two
options.

Questions:

Why doesn't unsuspendCmd use applyPatches to apply the unsuspended patches?
Why doesn't the doAdd helper "(repository'', renames) <- runHijackT
IgnoreHijack $ doAdd repository' ps_to_unsuspend" call mention anything
about the resolved patches? It only seems to use the patches that were
selected for unsuspending.

In addition to these specific questions, if I have anything incorrect or
gaps in my understanding please let me know!

As a first time contributor to Darcs I'm looking forward to improving it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osuosl.org/pipermail/darcs-devel/attachments/20171227/8924e8a0/attachment.html>


More information about the darcs-devel mailing list