Am 12.10.21 um 09:56 schrieb Alexis Praga:
Regarding interactive selection, it looks like the modifications should
be into applyCmdCommon from Apply.hs (unless I'm mistaken !).
Right.
However, I'm a bit confused about which patches should be offered for
selection. My first idea was to narrow it down to only patches with
conflicts (as the user already made a choice during the first selection phase).
So the first selection phase is about the patches from the bundle
("theirs", IOW the ones to be applied, which BTW you can already
pre-select in this way using the --skip-conflicts option).
The second phase would be selecting "our" patches (for removal). As I
sketched here http://bugs.darcs.net/msg22912, offering only patches that
are in conflict with those we selected in the first phase does make
sense as a merge strategy, but I think this should be a different option
(named "remove-conflicting" in the list I gave). I'd say let's
concentrate on getting --mirror (aka --remove aka --obliterate) right
before we move on to other strategies.
Cheers
Ben
Ben Franksen <ben.frank...@online.de> writes:
Go ahead. Feel free to amend my patch as you see fit (if you prefer to
keep it as is and add more patches, at least remove the "WIP"). You
could also try to add the option to the 'push' command.
BTW, adding interactive selection of the patches to obliterate in the
target repo means we have to think about what to do if not all patches
are selected. I guess you'll want to fall back to the standard merge for
what remains. And if we do that we might also want to drop the
restriction I added for simplicity, namely that there must not be any
unrecorded changes in the target repo.
We should also, perhaps, reconsider the name of the option, which fits
only the case when the user selects all patches.
Finally, since we now have two patch selection phases we have to choose
whether -a/--all affects both phases or only the first. This is similar
to 'rebase apply' and 'rebase pull' where the behavior is currently that
-a affects only the first phase.
Cheers
Ben
--
I would rather have questions that cannot be answered, than answers that
cannot be questioned. -- Richard Feynman
_______________________________________________
darcs-users mailing list
darcs-users@osuosl.org
https://lists.osuosl.org/mailman/listinfo/darcs-users
--
I would rather have questions that cannot be answered, than answers that
cannot be questioned. -- Richard Feynman
_______________________________________________
darcs-users mailing list
darcs-users@osuosl.org
https://lists.osuosl.org/mailman/listinfo/darcs-users
