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-10-05.09:00:35 by bf.

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
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