rebase pull/apply vs. pull/apply --rebase

Ben Franksen <[email protected]> Tue, 28 Jan 2020 11:37:21 +0100
Newsgroups	gmane.comp.version-control.darcs.user
Message-ID	<[email protected]>
I have been thinking again about the UI design question for rebase:
subcommand vs. option. What prompted me was the following scenario,
which I encountered just now:

Suppose you want to obliterate patch A. Perhaps it turned out that A
wasn't such a good idea after all. But you also have another patch B
that depends on A. You know that B is good, in principle, like a safe
and easy refactor, but one that would be tedious to redo manually. So
you would rather edit B i.e. suspend it.

It would be quite convenient to have a --rebase option for obliterate
that automatically suspends all patches that depend on the one(s) you
want to obliterate.

Note that this is something completely different than 'rebase
obliterate' which is about obliterating suspended patches. So this is a
point where the strict rule "everything that affects rebase must be a
subcommand of rebase" breaks down.

This prompted me to think a bit more about the existing rebase commands.
It appears we have to sorts of commands that affect the rebase state:

(1) Commands that are primarily targeted at the rebase state itself:
rebase suspend, rebase unsuspend, rebase log, and rebase obliterate.

(2) Commands that are primarily targeted at the regular repository state
and only affect the rebase state by suspending patches that are in the
way: rebase pull, rebase apply.

Perhaps for those in (2) an option would be preferable to a sub command.
Indeed a rebase pull/apply is just like a normal pull/apply, it just
treats conflicts in a different way.

To make it crystal clear what the expected behavior is, we could name
the option --suspend-conflicting. Commands from group (1) would remain
as they are. Commands from group (2) would get a different UI:

  rebase pull -> pull --suspend-conflicting
  rebase apply -> apply --suspend-conflicting

We could then add

  push --suspend-conflicting

(which I have been proposing some time ago) and also a new option
--suspend-depending to get

  obliterate --suspend-depending
  unrecord --suspend-depending
  amend --suspend-depending

Or we could shorten both options to just --suspend for more uniformity
(and less typing) but less clarity.

Another data point is that in the future we may want to offer even more
possibilities for treating conflicts (or dependencies that are in the
way). One feature I have in mind is a --branch option for push, pull,
apply, etc (mutually exclusive with --suspend) with the semantics of
creating a new branch for the conflicting patches. (This would be
similar in behavior to the once proposed stash command, but I believe
internal branches are the more powerful feature.)

One could also imagine a fully interactive solution: for each
conflicting patch we are asked whether we want to

 (a) keep it (create conflictors; only offered for pull,push,apply)
 (b) suspend it (for later editing)
 (c) put it on a branch (for later merging)
 (d) quit (abort the whole operation)

Such a UI would be quite inconsistent with the current UI for the rebase
related commands in group (2).

Cheers
Ben

_______________________________________________
darcs-users mailing list
[email protected]
https://lists.osuosl.org/mailman/listinfo/darcs-users
pEpkey.asc (application/pgp-keys, 4.1 KB)