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
pEpkey.asc
Description: application/pgp-keys
_______________________________________________ darcs-users mailing list darcs-users@osuosl.org https://lists.osuosl.org/mailman/listinfo/darcs-users
