| 1 | git-replay(1) |
| 2 | ============= |
| 3 | |
| 4 | NAME |
| 5 | ---- |
| 6 | git-replay - EXPERIMENTAL: Replay commits on a new base, works with bare repos too |
| 7 | |
| 8 | |
| 9 | SYNOPSIS |
| 10 | -------- |
| 11 | [verse] |
| 12 | (EXPERIMENTAL!) 'git replay' ([--contained] --onto=<newbase> | --advance=<branch> | --revert=<branch>) |
| 13 | [--ref=<ref>] [--ref-action=<mode>] <revision-range> |
| 14 | |
| 15 | DESCRIPTION |
| 16 | ----------- |
| 17 | |
| 18 | Takes a range of commits and replays them onto a new location. Leaves |
| 19 | the working tree and the index untouched. By default, updates the |
| 20 | relevant references using an atomic transaction (all refs update or |
| 21 | none). Use `--ref-action=print` to avoid automatic ref updates and |
| 22 | instead get update commands that can be piped to `git update-ref --stdin` |
| 23 | (see the <<output,OUTPUT>> section below). |
| 24 | |
| 25 | THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE. |
| 26 | |
| 27 | OPTIONS |
| 28 | ------- |
| 29 | |
| 30 | --onto=<newbase>:: |
| 31 | Starting point at which to create the new commits. May be any |
| 32 | valid commit, and not just an existing branch name. |
| 33 | + |
| 34 | When `--onto` is specified, the branch(es) in the revision range will be |
| 35 | updated to point at the new commits, similar to the way `git rebase --update-refs` |
| 36 | updates multiple branches in the affected range. |
| 37 | |
| 38 | --advance=<branch>:: |
| 39 | Starting point at which to create the new commits; must be a |
| 40 | branch name. |
| 41 | + |
| 42 | The history is replayed on top of the <branch> and <branch> is updated to |
| 43 | point at the tip of the resulting history. This is different from `--onto`, |
| 44 | which uses the target only as a starting point without updating it. |
| 45 | |
| 46 | --revert=<branch>:: |
| 47 | Starting point at which to create the reverted commits; must be a |
| 48 | branch name. |
| 49 | + |
| 50 | When `--revert` is specified, the commits in the revision range are reverted |
| 51 | (their changes are undone) and the reverted commits are created on top of |
| 52 | <branch>. The <branch> is then updated to point at the new commits. This is |
| 53 | the same as running `git revert <revision-range>` but does not update the |
| 54 | working tree. |
| 55 | + |
| 56 | The commit messages follow `git revert` conventions: they are prefixed with |
| 57 | "Revert" and include "This reverts commit <hash>." When reverting a commit |
| 58 | whose message starts with "Revert", the new message uses "Reapply" instead. |
| 59 | Unlike cherry-pick which preserves the original author, revert commits use |
| 60 | the current user as the author, matching the behavior of `git revert`. |
| 61 | + |
| 62 | This option is mutually exclusive with `--onto` and `--advance`. It is also |
| 63 | incompatible with `--contained` (which is a modifier for `--onto` only). |
| 64 | |
| 65 | --contained:: |
| 66 | Update all branches that point at commits in |
| 67 | <revision-range>. Requires `--onto`. |
| 68 | |
| 69 | --ref=<ref>:: |
| 70 | Override which reference is updated with the result of the replay. |
| 71 | The ref must be fully qualified. |
| 72 | When used with `--onto`, the `<revision-range>` should have a |
| 73 | single tip and only the specified reference is updated instead of |
| 74 | inferring refs from the revision range. |
| 75 | When used with `--advance` or `--revert`, the specified reference is |
| 76 | updated instead of the branch given to those options. |
| 77 | This option is incompatible with `--contained`. |
| 78 | |
| 79 | --ref-action[=<mode>]:: |
| 80 | Control how references are updated. The mode can be: |
| 81 | + |
| 82 | -- |
| 83 | //// |
| 84 | Expanded description list compared to 'replay.refAction'. |
| 85 | //// |
| 86 | `update`;; (default) Update refs directly using an atomic transaction. |
| 87 | All refs are updated or none are (all-or-nothing behavior). |
| 88 | `print`;; Output update-ref commands for pipeline use. This is the |
| 89 | traditional behavior where output can be piped to `git update-ref --stdin`. |
| 90 | -- |
| 91 | + |
| 92 | The default mode can be configured via the `replay.refAction` configuration variable. |
| 93 | |
| 94 | <revision-range>:: |
| 95 | Range of commits to replay; see "Specifying Ranges" in |
| 96 | linkgit:git-rev-parse[1]. In `--advance=<branch>` or |
| 97 | `--revert=<branch>` mode, the range should have a single tip, |
| 98 | so that it's clear to which tip the advanced or reverted |
| 99 | <branch> should point. Any commits in the range whose changes |
| 100 | are already present in the branch the commits are being |
| 101 | replayed onto will be dropped. |
| 102 | |
| 103 | :git-replay: 1 |
| 104 | include::rev-list-options.adoc[] |
| 105 | |
| 106 | [[output]] |
| 107 | OUTPUT |
| 108 | ------ |
| 109 | |
| 110 | By default, or with `--ref-action=update`, this command produces no output on |
| 111 | success, as refs are updated directly using an atomic transaction. |
| 112 | |
| 113 | When using `--ref-action=print`, the output is usable as input to |
| 114 | `git update-ref --stdin`. It is of the form: |
| 115 | |
| 116 | update refs/heads/branch1 ${NEW_branch1_HASH} ${OLD_branch1_HASH} |
| 117 | update refs/heads/branch2 ${NEW_branch2_HASH} ${OLD_branch2_HASH} |
| 118 | update refs/heads/branch3 ${NEW_branch3_HASH} ${OLD_branch3_HASH} |
| 119 | |
| 120 | where the number of refs updated depends on the arguments passed and |
| 121 | the shape of the history being replayed. When using `--advance` or |
| 122 | `--revert`, the number of refs updated is always one, but for `--onto`, |
| 123 | it can be one or more (rebasing multiple branches simultaneously is |
| 124 | supported). |
| 125 | |
| 126 | There is no stderr output on conflicts; see the <<exit-status,EXIT |
| 127 | STATUS>> section below. |
| 128 | |
| 129 | [[exit-status]] |
| 130 | EXIT STATUS |
| 131 | ----------- |
| 132 | |
| 133 | For a successful, non-conflicted replay, the exit status is 0. When |
| 134 | the replay has conflicts, the exit status is 1. If the replay is not |
| 135 | able to complete (or start) due to some kind of error, the exit status |
| 136 | is something other than 0 or 1. |
| 137 | |
| 138 | EXAMPLES |
| 139 | -------- |
| 140 | |
| 141 | To simply rebase `mybranch` onto `target`: |
| 142 | |
| 143 | ------------ |
| 144 | $ git replay --onto=target origin/main..mybranch |
| 145 | ------------ |
| 146 | |
| 147 | The refs are updated atomically and no output is produced on success. |
| 148 | |
| 149 | To see what would be updated without actually updating: |
| 150 | |
| 151 | ------------ |
| 152 | $ git replay --ref-action=print --onto=target origin/main..mybranch |
| 153 | update refs/heads/mybranch ${NEW_mybranch_HASH} ${OLD_mybranch_HASH} |
| 154 | ------------ |
| 155 | |
| 156 | To cherry-pick the commits from mybranch onto target: |
| 157 | |
| 158 | ------------ |
| 159 | $ git replay --advance=target origin/main..mybranch |
| 160 | ------------ |
| 161 | |
| 162 | Note that the first two examples replay the exact same commits and on |
| 163 | top of the exact same new base, they only differ in that the first |
| 164 | updates mybranch to point at the new commits and the second updates |
| 165 | target to point at them. |
| 166 | |
| 167 | What if you have a stack of branches, one depending upon another, and |
| 168 | you'd really like to rebase the whole set? |
| 169 | |
| 170 | ------------ |
| 171 | $ git replay --contained --onto=origin/main origin/main..tipbranch |
| 172 | ------------ |
| 173 | |
| 174 | All three branches (`branch1`, `branch2`, and `tipbranch`) are updated |
| 175 | atomically. |
| 176 | |
| 177 | When calling `git replay`, one does not need to specify a range of |
| 178 | commits to replay using the syntax `A..B`; any range expression will |
| 179 | do: |
| 180 | |
| 181 | ------------ |
| 182 | $ git replay --onto=origin/main ^base branch1 branch2 branch3 |
| 183 | ------------ |
| 184 | |
| 185 | This will simultaneously rebase `branch1`, `branch2`, and `branch3`, |
| 186 | all commits they have since `base`, playing them on top of |
| 187 | `origin/main`. These three branches may have commits on top of `base` |
| 188 | that they have in common, but that does not need to be the case. |
| 189 | |
| 190 | To revert commits on a branch: |
| 191 | |
| 192 | ------------ |
| 193 | $ git replay --revert=main topic~2..topic |
| 194 | ------------ |
| 195 | |
| 196 | This reverts the last two commits from `topic`, creating revert commits on |
| 197 | top of `main`, and updates `main` to point at the result. This is useful when |
| 198 | commits from `topic` were previously merged or cherry-picked into `main` and |
| 199 | need to be undone. |
| 200 | |
| 201 | NOTE: For reverting an entire merge request as a single commit (rather than |
| 202 | commit-by-commit), consider using `git merge-tree --merge-base $TIP HEAD $BASE` |
| 203 | which can avoid unnecessary merge conflicts. |
| 204 | |
| 205 | To replay onto a specific commit while updating a different reference: |
| 206 | |
| 207 | ------------ |
| 208 | $ git replay --onto=112233 --ref=refs/heads/mybranch aabbcc..ddeeff |
| 209 | ------------ |
| 210 | |
| 211 | This replays the range `aabbcc..ddeeff` onto commit `112233` and updates |
| 212 | `refs/heads/mybranch` to point at the result. This can be useful when you want |
| 213 | to use bare commit IDs instead of branch names. |
| 214 | |
| 215 | CONFIGURATION |
| 216 | ------------- |
| 217 | :git-replay: 1 |
| 218 | include::config/replay.adoc[] |
| 219 | |
| 220 | GIT |
| 221 | --- |
| 222 | Part of the linkgit:git[1] suite |