128 lines
		
	
	
		
			4.3 KiB
		
	
	
	
		
			Plaintext
		
	
	
			
		
		
	
	
			128 lines
		
	
	
		
			4.3 KiB
		
	
	
	
		
			Plaintext
		
	
	
| 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
 |