From 9d8d8462371824f26e88c5924f5951f4c106abc0 Mon Sep 17 00:00:00 2001 From: "jj-docs[bot]" Date: Tue, 21 Jan 2025 06:54:37 +0000 Subject: [PATCH] Deployed be32d4e to prerelease with MkDocs 1.6.1 and mike 2.1.3 --- prerelease/cli-reference/index.html | 57 ++++++++++++++++++++++------- prerelease/search/search_index.json | 2 +- 2 files changed, 44 insertions(+), 15 deletions(-) diff --git a/prerelease/cli-reference/index.html b/prerelease/cli-reference/index.html index 9598e2dfc..a28f5e1c2 100644 --- a/prerelease/cli-reference/index.html +++ b/prerelease/cli-reference/index.html @@ -7794,10 +7794,15 @@ A A

jj rebase

Move revisions to different parent(s)

-

There are three different ways of specifying which revisions to rebase: --b to rebase a whole branch, -s to rebase a revision and its -descendants, and -r to rebase a single commit. If none of them is -specified, it defaults to -b @.

+

This command moves revisions to different parent(s) while preserving the +changes (diff) in the revisions.

+

There are three different ways of specifying which revisions to rebase:

+ +

If no option is specified, it defaults to -b @.

With -s, the command rebases the specified revision and its descendants onto the destination. For example, jj rebase -s M -d O would transform your history like this (letters followed by an apostrophe are post-rebase @@ -7814,14 +7819,18 @@ versions):

|/ |/ J J +

Each revision passed to -s will become a direct child of the destination, +so if you instead run jj rebase -s M -s N -d O (or +jj rebase -s 'all:M|N' -d O) in the example above, then N' would instead +be a direct child of O.

With -b, the command rebases the whole "branch" containing the specified -revision. A "branch" is the set of commits that includes:

+revision. A "branch" is the set of revisions that includes:

-

In other words, jj rebase -b X -d Y rebases commits in the revset +

In other words, jj rebase -b X -d Y rebases revisions in the revset (Y..X):: (which is equivalent to jj rebase -s 'roots(Y..X)' -d Y for a single root). For example, either jj rebase -b L -d O or jj rebase -b M -d O would transform your history like this (because L and M are on the @@ -7840,7 +7849,7 @@ J J

With -r, the command rebases only the specified revisions onto the destination. Any "hole" left behind will be filled by rebasing descendants -onto the specified revision's parent(s). For example, jj rebase -r K -d M +onto the specified revisions' parent(s). For example, jj rebase -r K -d M would transform your history like this:

M          K'
 |          |
@@ -7850,10 +7859,30 @@ would transform your history like this:

 |/         |/
 J          J
-

Note that you can create a merge commit by repeating the -d argument. -For example, if you realize that commit L actually depends on commit M in -order to work (in addition to its current parent K), you can run jj rebase --s L -d K -d M:

+

Multiple revisions can be specified, and any dependencies (graph edges) +within the set will be preserved. For example, jj rebase -r 'K|N' -d O +would transform your history like this:

+
O           N'
+|           |
+| N         K'
+| |         |
+| M         O
+| |    =>   |
+| | L       | M'
+| |/        |/
+| K         | L'
+|/          |/
+J           J
+
+

jj rebase -s X is similar to jj rebase -r X:: and will behave the same +if X is a single revision. However, if X is a set of multiple revisions, +or if you passed multiple -s arguments, then jj rebase -s will make each +of the specified revisions an immediate child of the destination, while +jj rebase -r will preserve dependencies within the set.

+

Note that you can create a merge revision by repeating the -d argument. +For example, if you realize that revision L actually depends on revision M +in order to work (in addition to its current parent K), you can run jj +rebase -s L -d K -d M:

M          L'
 |          |\
 | L        M |
@@ -7862,8 +7891,8 @@ order to work (in addition to its current parent K), you can run jj rebase
 |/         |/
 J          J
-

If a working-copy commit gets abandoned, it will be given a new, empty -commit. This is true in general; it is not specific to this command.

+

If a working-copy revision gets abandoned, it will be given a new, empty +revision. This is true in general; it is not specific to this command.

Usage: jj rebase [OPTIONS] <--destination <REVSETS>|--insert-after <REVSETS>|--insert-before <REVSETS>>

Options: