|  | git-replay(1) | 
|  | ============= | 
|  |  | 
|  | NAME | 
|  | ---- | 
|  | git-replay - EXPERIMENTAL: Replay commits on a new base, works with bare repos too | 
|  |  | 
|  |  | 
|  | SYNOPSIS | 
|  | -------- | 
|  | [verse] | 
|  | (EXPERIMENTAL!) 'git replay' ([--contained] --onto <newbase> | --advance <branch>) <revision-range>... | 
|  |  | 
|  | DESCRIPTION | 
|  | ----------- | 
|  |  | 
|  | Takes ranges of commits and replays them onto a new location. Leaves | 
|  | the working tree and the index untouched, and updates no references. | 
|  | The output of this command is meant to be used as input to | 
|  | `git update-ref --stdin`, which would update the relevant branches | 
|  | (see the OUTPUT section below). | 
|  |  | 
|  | THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE. | 
|  |  | 
|  | OPTIONS | 
|  | ------- | 
|  |  | 
|  | --onto <newbase>:: | 
|  | Starting point at which to create the new commits.  May be any | 
|  | valid commit, and not just an existing branch name. | 
|  | + | 
|  | When `--onto` is specified, the update-ref command(s) in the output will | 
|  | update the branch(es) in the revision range to point at the new | 
|  | commits, similar to the way how `git rebase --update-refs` updates | 
|  | multiple branches in the affected range. | 
|  |  | 
|  | --advance <branch>:: | 
|  | Starting point at which to create the new commits; must be a | 
|  | branch name. | 
|  | + | 
|  | When `--advance` is specified, the update-ref command(s) in the output | 
|  | will update the branch passed as an argument to `--advance` to point at | 
|  | the new commits (in other words, this mimics a cherry-pick operation). | 
|  |  | 
|  | <revision-range>:: | 
|  | Range of commits to replay. More than one <revision-range> can | 
|  | be passed, but in `--advance <branch>` mode, they should have | 
|  | a single tip, so that it's clear where <branch> should point | 
|  | to. See "Specifying Ranges" in linkgit:git-rev-parse[1] and the | 
|  | "Commit Limiting" options below. | 
|  |  | 
|  | include::rev-list-options.adoc[] | 
|  |  | 
|  | OUTPUT | 
|  | ------ | 
|  |  | 
|  | When there are no conflicts, the output of this command is usable as | 
|  | input to `git update-ref --stdin`.  It is of the form: | 
|  |  | 
|  | update refs/heads/branch1 ${NEW_branch1_HASH} ${OLD_branch1_HASH} | 
|  | update refs/heads/branch2 ${NEW_branch2_HASH} ${OLD_branch2_HASH} | 
|  | update refs/heads/branch3 ${NEW_branch3_HASH} ${OLD_branch3_HASH} | 
|  |  | 
|  | where the number of refs updated depends on the arguments passed and | 
|  | the shape of the history being replayed.  When using `--advance`, the | 
|  | number of refs updated is always one, but for `--onto`, it can be one | 
|  | or more (rebasing multiple branches simultaneously is supported). | 
|  |  | 
|  | EXIT STATUS | 
|  | ----------- | 
|  |  | 
|  | For a successful, non-conflicted replay, the exit status is 0.  When | 
|  | the replay has conflicts, the exit status is 1.  If the replay is not | 
|  | able to complete (or start) due to some kind of error, the exit status | 
|  | is something other than 0 or 1. | 
|  |  | 
|  | EXAMPLES | 
|  | -------- | 
|  |  | 
|  | To simply rebase `mybranch` onto `target`: | 
|  |  | 
|  | ------------ | 
|  | $ git replay --onto target origin/main..mybranch | 
|  | update refs/heads/mybranch ${NEW_mybranch_HASH} ${OLD_mybranch_HASH} | 
|  | ------------ | 
|  |  | 
|  | To cherry-pick the commits from mybranch onto target: | 
|  |  | 
|  | ------------ | 
|  | $ git replay --advance target origin/main..mybranch | 
|  | update refs/heads/target ${NEW_target_HASH} ${OLD_target_HASH} | 
|  | ------------ | 
|  |  | 
|  | Note that the first two examples replay the exact same commits and on | 
|  | top of the exact same new base, they only differ in that the first | 
|  | provides instructions to make mybranch point at the new commits and | 
|  | the second provides instructions to make target point at them. | 
|  |  | 
|  | What if you have a stack of branches, one depending upon another, and | 
|  | you'd really like to rebase the whole set? | 
|  |  | 
|  | ------------ | 
|  | $ git replay --contained --onto origin/main origin/main..tipbranch | 
|  | update refs/heads/branch1 ${NEW_branch1_HASH} ${OLD_branch1_HASH} | 
|  | update refs/heads/branch2 ${NEW_branch2_HASH} ${OLD_branch2_HASH} | 
|  | update refs/heads/tipbranch ${NEW_tipbranch_HASH} ${OLD_tipbranch_HASH} | 
|  | ------------ | 
|  |  | 
|  | When calling `git replay`, one does not need to specify a range of | 
|  | commits to replay using the syntax `A..B`; any range expression will | 
|  | do: | 
|  |  | 
|  | ------------ | 
|  | $ git replay --onto origin/main ^base branch1 branch2 branch3 | 
|  | update refs/heads/branch1 ${NEW_branch1_HASH} ${OLD_branch1_HASH} | 
|  | update refs/heads/branch2 ${NEW_branch2_HASH} ${OLD_branch2_HASH} | 
|  | update refs/heads/branch3 ${NEW_branch3_HASH} ${OLD_branch3_HASH} | 
|  | ------------ | 
|  |  | 
|  | This will simultaneously rebase `branch1`, `branch2`, and `branch3`, | 
|  | all commits they have since `base`, playing them on top of | 
|  | `origin/main`. These three branches may have commits on top of `base` | 
|  | that they have in common, but that does not need to be the case. | 
|  |  | 
|  | GIT | 
|  | --- | 
|  | Part of the linkgit:git[1] suite |