FR: Generalizable and reusable "rebase behavior"

[arxanas]

Is your feature request related to a problem? Please describe.

There's been a proliferation of flags added to various commands that create or rebase commits. For example, --insert-before/--insert-after should be added to many commands, but hasn't been yet. Rebasing is a core competency and reason to use jj. I think we should invest in a unified flexible design to control "rebase behavior" rather than add more flags.

Most commands that create or rebase commits could reuse some of these options, including:

• jj abandon
• jj commit
• jj describe
• jj duplicate
• jj new
• jj parallelize
• jj rebase
• jj split
• jj squash

Describe the solution you'd like

Roughly speaking jj rebase --dest X (and similar for other commands) should accept an expression representing "rebase behavior" (and also accept a revset for backward compatibility and the common case).

As an example, suppose you're using a "mega-merge" strategy. You have a bunch of commits in X that you want to insert before the mega-merge commit as standalone commits. You want to take this opportunity to also write some helpful messages for each commit. If this wouldn't merge cleanly, then you want to abort the operation rather than produce conflicts. An example invocation might look like this:

$ jj rebase -r X -d 'behavior(after=trunk(), before=@, topology="horizontal", empty="keep", message="prompt", merge="abort")'

However, if you have a commit in X and you need to split it as part of doing the mega-merge, then maybe you'll issue an invocation like this:

$ jj split -r X -d 'behavior(after=trunk(), before=@, topology="horizontal", message="prompt", merge="ours")'

To demonstrate the general applicability of this design, see the issues linked below.

Given a commit set X that's being rebased, the following are some relevant axes to control rebase behavior:

• Location: one or more of the following:
  • "after" revset Y: commit set X is rebased to be children of Y. This is the current behavior of jj rebase -r X -d Y.
  • "before" revset Z: after rebasing the commit set, the commits in Z will be rebased as children of it. This is the current behavior of jj rebase -r X --insert-before Z.
  • related: "replace" revset W: abandon the commits in W and behave as if W's parents were provided for after and W's children were provided for before.
  • See: jj rebase -r should be able to rebase a commit onto its descendant, insert commits before or after another commit (now AKA better tools for reordering commits part 1) #1188, FR: reorder AKA histedit command (better tools for reordering commits part 2) #1531, FR: jj duplicate -d #3518, FR: Add --insert-before and --insert-after to split, new, duplicate, etc. #3772, FR: when abandoning the working copy, use the same children for the new change #4468
• Topology: exactly one of the following:
  • "preserve": Default. If a commit in X was an ancestor of another commit in X before the rebase, then it remains so after the rebase. This is the current behavior of jj rebase.
  • "horizontal": Commits in X are rebased individually to be siblings. This is the behavior of jj parallelize.
  • "vertical": Commits in X are rebased to be a chain of children (in an arbitrary order). No current equivalent.
  • See: Add a jj parallelize command #1079, FR: jj split --horizontal/--siblings/--sideways #2274, jj unexpectedly simplifies ancestry when rewriting a commit that is both a direct child and an indirect descendant of another commit #2600, Don't introduce new redundant ancestor merges when auto-rebasing #4351
• Signature: for each combination of author/committer + name/email/timestamp:
  • "preserve": Default. Preserve the existing signature value.
  • "set" to Y: Set the signature value to Y. Some current equivalents.
  • "reset": Overwrite the signature value to the current user's signature value. Some current equivalents.
  • Potentially something about GPG-signing?
  • See: support for signed commits #58, Need a way of setting name/email/timestamp for author/committer #328, FR: Better handling of author dates (as opposed to committer dates) #2000, FR: Update author timestamp when initally committing change #3008, Omit or disallow merge parents to be ancestors #3565, FR: Equivalent to git commit's --author <id> option in jj {desc,commit} #4170
• Message:
  • "preserve": Default. Preserve the existing message.
  • "set" to Y: For each commit in X, set the message to string (or template) Y.
  • "prompt": Interactively prompt to edit all messages for commits in X.
  • related: "add/set footer": Add or set a Git footer for the commit.
  • See Better jj split ergonomics #1155, FR: Improve jj backout generated description #2669, FR: jj split --message, like jj commit --message #3060
• Empty commits:
  • "drop": Default. Drop any commits in X that are empty.
  • "preserve": Preserve all commits in X, even those that are empty.
  • "keep": Drop commits in X that were non-empty before the rebase but empty after the rebase. (Should this be the new default?) Related to --keep-emptied.
  • related: "deduplicate": Determine if any commits have already been applied via patch ID semantics.
  • See: Drop commits that were made empty by rebase #229, Implement jj sync command #1039, FR: add "signed-off-by" line #1399, FR: --allow-empty for squash and unsquash. #1406, FR: git commit --verbose equivalent for jj describe #1946, FR: better detection of commits that were made empty #2979, FR: support for bulk-editing of commit descriptions #3120, rebase --skip-empty on merge commits doesn't remove deleted parents #3766, FR: Implement jj git sync #4641, FR: Configuration setting to use --keep-emptied by default when squashing #4668
• Change ID:
  • "preserve": Default. Preserve the existing change ID.
  • "set" to Y: Set the change ID to Y explicitly. No current equivalent.
  • "reset": Overwrite the change ID with a freshly-generated one. No current equivalent.
  • See: [git] Feature request: track commit rewriting from Git #490, FR: Command for resetting change ID #4451
• Conflict resolution:
  • "preserve": Default. Allow conflicts to be generated and recorded.
  • "reparent": Set the parents of commits in X without actually doing "rebasing" (patch application).
  • "abort": If conflicts would be generated, instead abort the operation.
  • "ours"/"theirs": When conflicts are generated, use one of the sides to resolve them. (There are several additional aspects that can be configured here.)
  • See: Add rename detection #47, Report new conflicts created by an operation #555, Option to rebase/amend verbatim (like "ours" merge strategy) #1027, FR: manually track moves and copies #3386, FR: Improve conflict resolving for binary files #3540, Design: basic, generalized footer support for change descriptions #2849, FR: Support jj fix -r X to fix X with minimal effects on X.. #3805, Consider not partially resolving merged trees #4152
• Bookmark moving:
  • Not sure about this one, but there might be generally-relevant configuration. If we adopt topics instead of bookmarks, then it might also make sense to configure topic behavior here.
  • See: FR: --advance-branches flag for jj commit #2338, What should jj split do with branches? #3419, FR: Stop branches from sliding back on jj abandon, delete them instead #3505, FR: Support jj fix -r X to fix X with minimal effects on X.. #3805

Describe alternatives you've considered

• Preserve current behavior. Add flags to each command that might need them. I think it's extra work overall and results in a less flexible/coherent system. However, command-line flags are generally more discoverable/accessible than the revset language.

Additional context

This also covers some use-cases for #3814, but is not a complete substitute.

[joyously]

This seems like a lot of options. Hopefully, all will be considered in the context of undo and of simultaneous access (scripts in two windows).

[arxanas]

This seems like a lot of options. Hopefully, all will be considered in the context of undo and of simultaneous access (scripts in two windows).

I don't think we need to do anything special to support undo for this design. I believe we basically snapshot the repo before and after the operation, without regard to which operations actually ran. Simultaneous modifications are a problem, but not specific to this either.