mirror of
https://github.com/git/git.git
synced 2024-12-01 05:54:16 +08:00
f412d72c19
In git-replay documentation, linkgit to git-rev-parse is missing the man section, which breaks its rendering. Add section number as done in other references to this command. Signed-off-by: Yehezkel Bernat <YehezkelShB@gmail.com> Acked-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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.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. 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
|