cli rebase: do not allow -r --skip-empty to empty descendants

This follows up on @matts1 's jj-vcs#2609.

We still allow the `-r` commit to become empty. I would be more comfortable if
there was a test for that, but I haven't done that (yet?) and it seems pretty
safe. If that's a problem, I'm happy to forbid `-r --skip-empty` entirely,
since it is far less useful than `-s --skip-empty` or `-b --skip-empty`.

I think it is reasonable not to empty descendants, since as far as descendants
of `A` are concerned, `jj rebase -r A` should be equivalent to `jj abandon A`,
and `jj abandon` does not remove emptid commits. It also doesn't seem very
useful to do that to descendant commits.

Moreover, if we did want -r to empty descendants of `A`, we'd have to improve the
algorithm and add thorough tests. For example, if we have

```
root -> A -> B -> C
```

and `jj rebase -r A -d C` empties commit `B` (or `C`), I do not know whether the
current algorithm will work correctly. It seems possible that it would, but that
depends on the fact that empty merge commits are not abandoned. That seems
dangerous to rely on without tests.

cli/src/commands/rebase.rs

@@ -22,7 +22,7 @@ use jj_lib::backend::{CommitId, ObjectId};
 use jj_lib::commit::Commit;
 use jj_lib::repo::{ReadonlyRepo, Repo};
 use jj_lib::revset::{RevsetExpression, RevsetIteratorExt};
-use jj_lib::rewrite::{rebase_commit_with_options, EmptyBehaviour, RebaseOptions};
+use jj_lib::rewrite::{rebase_commit, rebase_commit_with_options, EmptyBehaviour, RebaseOptions};
 use jj_lib::settings::UserSettings;
 use tracing::instrument;
 
@@ -185,7 +185,7 @@ Please use `jj rebase -d 'all:x|y'` instead of `jj rebase --allow-large-revsets
             &mut workspace_command,
             &new_parents,
             rev_str,
-            &rebase_options,
+            &RebaseOptions::default(),
         )?;
     } else if !args.source.is_empty() {
         let source_commits =
@@ -357,22 +357,16 @@ fn rebase_revision(
 
         rebased_commit_ids.insert(
             child_commit.id().clone(),
-            rebase_commit_with_options(
-                settings,
-                tx.mut_repo(),
-                child_commit,
-                &new_child_parents,
-                rebase_options,
-            )?
-            .id()
-            .clone(),
+            rebase_commit(settings, tx.mut_repo(), child_commit, &new_child_parents)?
+                .id()
+                .clone(),
         );
     }
     // Now, rebase the descendants of the children.
-    rebased_commit_ids.extend(
-        tx.mut_repo()
-            .rebase_descendants_return_map(settings, rebase_options.clone())?,
-    );
+    // TODO(ilyagr): Consider making it possible for these decendants to become
+    // emptied, like --skip_empty. This would require obtaining more information
+    // than `rebase_descendants_return_map` can provide.
+    rebased_commit_ids.extend(tx.mut_repo().rebase_descendants_return_map(settings)?);
     let num_rebased_descendants = rebased_commit_ids.len();
 
     // We now update `new_parents` to account for the rebase of all of
@@ -405,11 +399,7 @@ fn rebase_revision(
         &new_parents,
         rebase_options,
     )?;
-    debug_assert_eq!(
-        tx.mut_repo()
-            .rebase_descendants_with_options(settings, rebase_options.clone())?,
-        0
-    );
+    debug_assert_eq!(tx.mut_repo().rebase_descendants(settings)?, 0);
 
     if num_rebased_descendants > 0 {
         writeln!(

lib/src/repo.rs

@@ -881,10 +881,9 @@ impl MutableRepo {
     pub fn rebase_descendants_return_map(
         &mut self,
         settings: &UserSettings,
-        options: RebaseOptions,
     ) -> Result<HashMap<CommitId, CommitId>, TreeMergeError> {
         Ok(self
-            .rebase_descendants_return_rebaser(settings, options)?
+            .rebase_descendants_return_rebaser(settings, Default::default())?
             .map_or(HashMap::new(), |rebaser| rebaser.rebased().clone()))
     }