2023-11-24 11:10:31 +00:00
|
|
|
git-replay(1)
|
|
|
|
=============
|
|
|
|
|
|
|
|
NAME
|
|
|
|
----
|
|
|
|
git-replay - EXPERIMENTAL: Replay commits on a new base, works with bare repos too
|
|
|
|
|
|
|
|
|
|
|
|
SYNOPSIS
|
|
|
|
--------
|
|
|
|
[verse]
|
2023-11-24 11:10:40 +00:00
|
|
|
(EXPERIMENTAL!) 'git replay' --onto <newbase> <revision-range>...
|
2023-11-24 11:10:31 +00:00
|
|
|
|
|
|
|
DESCRIPTION
|
|
|
|
-----------
|
|
|
|
|
2023-11-24 11:10:40 +00:00
|
|
|
Takes ranges of commits and replays them onto a new location. Leaves
|
2023-11-24 11:10:39 +00:00
|
|
|
the working tree and the index untouched, and updates no references.
|
|
|
|
The output of this command is meant to be used as input to
|
2023-11-24 11:10:40 +00:00
|
|
|
`git update-ref --stdin`, which would update the relevant branches
|
|
|
|
(see the OUTPUT section below).
|
2023-11-24 11:10:31 +00:00
|
|
|
|
|
|
|
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.
|
2023-11-24 11:10:40 +00:00
|
|
|
+
|
|
|
|
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.
|
|
|
|
|
|
|
|
<revision-range>::
|
|
|
|
Range of commits to replay; see "Specifying Ranges" in
|
|
|
|
linkgit:git-rev-parse and the "Commit Limiting" options below.
|
|
|
|
|
|
|
|
include::rev-list-options.txt[]
|
|
|
|
|
|
|
|
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.
|
2023-11-24 11:10:31 +00:00
|
|
|
|
|
|
|
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.
|
|
|
|
|
2023-11-24 11:10:40 +00:00
|
|
|
EXAMPLES
|
|
|
|
--------
|
|
|
|
|
|
|
|
To simply rebase `mybranch` onto `target`:
|
|
|
|
|
|
|
|
------------
|
|
|
|
$ git replay --onto target origin/main..mybranch
|
|
|
|
update refs/heads/mybranch ${NEW_mybranch_HASH} ${OLD_mybranch_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.
|
|
|
|
|
2023-11-24 11:10:31 +00:00
|
|
|
GIT
|
|
|
|
---
|
|
|
|
Part of the linkgit:git[1] suite
|