Issue 2552 darcs rebase unsuspend --all should stop at the first conflict

Title darcs rebase unsuspend --all should stop at the first conflict
Priority feature Status unknown
Milestone Resolved in
Superseder Nosy List bf
Assigned To

Created on 2017-10-04.20:44:12 by bf, last changed 2017-12-18.14:33:15 by danielwilsonthomas.

msg19698 (view) Author: bf Date: 2017-10-04.20:44:10
The idea is that sometimes I want to unsuspend everything, but only if
that does not result in conflicts. As soon as there are conflicts, the
unsuspend should stop, allowing me to resolve the conflict before I
continue (by issuing the same command again).

Rationale: rebase unsuspend will give your patches a new identity
anyway, so it makes sense to use amend after resolving conflicts. But
you can do that only if no other patches depend on the one that has the
conflict. At the moment, I must unsuspend one patch at a time, so I
don't get all the conflicts in one big heap afterwards. Besides,
resolving conflicts is *much* easier when you do it right at the point
where the conflict happens.
msg19701 (view) Author: ganesh Date: 2017-10-05.05:33:42
'--skip-conflicts' should avoid any conflicting patches (and of course 
their dependencies). Is that enough, or do you want to avoid getting 
the unsuspended patches out of order?
msg19703 (view) Author: bf Date: 2017-10-05.09:00:34
Fascinating. I am using (and hacking on) darcs so heavily and for such a
long time and still don't know about all the options ;-) So... thanks
for reminding me of --skip-conflicts. I don't think getting patches out
of order is a problem because when you rebase the order usually gets
shuffled pretty much anyway. And yes, --skip-conflicts would help to
first get rid of all non-conflicting patches in one go.

It doesn't /quite/ cut it, though, because I may still be left with more
than one patch and then have to unsuspend them one at a time, as I did
before. And i don't like that i have to use the same command first with
one option and then with another one. Anyway, thinking about what
--skip-conflicts does made gave me another idea:

I would be perfectly fine if patch selection would just /tell/ me that a
patch will conflict, /right at the point where the patch is offered/.
Then I could tell it to stop there or i could select it and then tell it
to stop or whatever. Given that --skip-conflicts is able to detect
conflicting patches before they are selected, i think that should be
possible. The behavior would be fully compatible and does not need a new
option and is also exactly the same for all commands.

We could still add an option --prompt-conflicts to make the UI safer to
use. This would ask the user to confirm selection of a patch when
selecting that patch leads to a conflict. I even think that, in the long
run, this should become the default behavior for all commands that can
potentially introduce conflicts i.e. push, pull, apply, rebase unsuspend
msg19808 (view) Author: danielwilsonthomas Date: 2017-12-18.14:33:04
Without this, it seems pretty easy to lose track of the changes you amended into a previous patch which 
has dependents.

For example, the following sequence of commands results in a state that, while all the information seems 
to present in some form, looks like it's lost some information.

darcs init
echo "Some text here" > file1
darcs record -m "Gonna edit this later" -a -l
echo "Some more text" >> file1
darcs record -m "Gonna suspend this 1" -a
echo "Suspending two" >> file1
darcs record -m "Gonna suspend this 2" -a
darcs rebase suspend -p "Gonna suspend this" --no-interactive
echo "Edited this" >> file1
darcs amend --record --all # Amend into "edit this" patch
darcs rebase unsuspend --all

After this sequence of commands (the only one I couldn't make non-interactive seemed to be the amend-
record) there are some conflict markers in file1, but the the "Edited this" text is not in those conflict 
markers. Here's the contents of file1:

# file1:
Some text here
v v v v v v v
Some more text
Some more text
Suspending two
^ ^ ^ ^ ^ ^ ^

And here's the output of darcs log -v

patch 11abf7f827912edd2481c2cd46da2ebd449bdedc
Author: danielwilsonthomas.com
Date:   Mon Dec 18 08:52:00 EST 2017
  * Gonna suspend this 2
    hunk ./file1 2
    +Some more text

patch d6ebc481d5bfab4de5f3485fcb8b044f7016d6b9
Author: danielwilsonthomas.com
Date:   Mon Dec 18 08:52:00 EST 2017
  * Gonna suspend this 1
    hunk ./file1 2
    -Edited this

patch 6c0bdc6a6ae82d78b3cc5d1e34f3e5da7d3cf36e
Author: danielwilsonthomas.com
Date:   Mon Dec 18 08:51:51 EST 2017
  * Gonna edit this later
    addfile ./file1
    hunk ./file1 1
    +Some text here
    +Edited this

You can see the line was removed in the "Gonna suspend this 1" patch.
Date User Action Args
2017-10-04 20:44:12bfcreate
2017-10-04 20:55:42bfsetpriority: feature
2017-10-05 05:33:43ganeshsetmessages: + msg19701
2017-10-05 09:00:35bfsetmessages: + msg19703
2017-12-18 14:33:15danielwilsonthomassetmessages: + msg19808