made the pack completely portable and wrote relevent bat files to go with it
This commit is contained in:
Draqoken
127
gitportable/mingw64/share/doc/git-doc/git-replay.adoc
Normal file
127
gitportable/mingw64/share/doc/git-doc/git-replay.adoc
Normal file
@@ -0,0 +1,127 @@
|
||||
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
|
||||
Reference in New Issue
Block a user