]>
Commit | Line | Data |
---|---|---|
f920b028 EN |
1 | git-replay(1) |
2 | ============= | |
3 | ||
4 | NAME | |
5 | ---- | |
6 | git-replay - EXPERIMENTAL: Replay commits on a new base, works with bare repos too | |
7 | ||
8 | ||
9 | SYNOPSIS | |
10 | -------- | |
11 | [verse] | |
c4611130 | 12 | (EXPERIMENTAL!) 'git replay' ([--contained] --onto <newbase> | --advance <branch>) <revision-range>... |
f920b028 EN |
13 | |
14 | DESCRIPTION | |
15 | ----------- | |
16 | ||
3916ec30 | 17 | Takes ranges of commits and replays them onto a new location. Leaves |
81613be3 EN |
18 | the working tree and the index untouched, and updates no references. |
19 | The output of this command is meant to be used as input to | |
3916ec30 EN |
20 | `git update-ref --stdin`, which would update the relevant branches |
21 | (see the OUTPUT section below). | |
f920b028 EN |
22 | |
23 | THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE. | |
24 | ||
25 | OPTIONS | |
26 | ------- | |
27 | ||
28 | --onto <newbase>:: | |
29 | Starting point at which to create the new commits. May be any | |
30 | valid commit, and not just an existing branch name. | |
3916ec30 | 31 | + |
22d99f01 EN |
32 | When `--onto` is specified, the update-ref command(s) in the output will |
33 | update the branch(es) in the revision range to point at the new | |
34 | commits, similar to the way how `git rebase --update-refs` updates | |
35 | multiple branches in the affected range. | |
36 | ||
37 | --advance <branch>:: | |
38 | Starting point at which to create the new commits; must be a | |
39 | branch name. | |
40 | + | |
41 | When `--advance` is specified, the update-ref command(s) in the output | |
42 | will update the branch passed as an argument to `--advance` to point at | |
43 | the new commits (in other words, this mimics a cherry-pick operation). | |
3916ec30 EN |
44 | |
45 | <revision-range>:: | |
22d99f01 EN |
46 | Range of commits to replay. More than one <revision-range> can |
47 | be passed, but in `--advance <branch>` mode, they should have | |
48 | a single tip, so that it's clear where <branch> should point | |
49 | to. See "Specifying Ranges" in linkgit:git-rev-parse and the | |
50 | "Commit Limiting" options below. | |
3916ec30 EN |
51 | |
52 | include::rev-list-options.txt[] | |
53 | ||
54 | OUTPUT | |
55 | ------ | |
56 | ||
57 | When there are no conflicts, the output of this command is usable as | |
58 | input to `git update-ref --stdin`. It is of the form: | |
59 | ||
60 | update refs/heads/branch1 ${NEW_branch1_HASH} ${OLD_branch1_HASH} | |
61 | update refs/heads/branch2 ${NEW_branch2_HASH} ${OLD_branch2_HASH} | |
62 | update refs/heads/branch3 ${NEW_branch3_HASH} ${OLD_branch3_HASH} | |
63 | ||
64 | where the number of refs updated depends on the arguments passed and | |
22d99f01 EN |
65 | the shape of the history being replayed. When using `--advance`, the |
66 | number of refs updated is always one, but for `--onto`, it can be one | |
67 | or more (rebasing multiple branches simultaneously is supported). | |
f920b028 EN |
68 | |
69 | EXIT STATUS | |
70 | ----------- | |
71 | ||
72 | For a successful, non-conflicted replay, the exit status is 0. When | |
73 | the replay has conflicts, the exit status is 1. If the replay is not | |
74 | able to complete (or start) due to some kind of error, the exit status | |
75 | is something other than 0 or 1. | |
76 | ||
3916ec30 EN |
77 | EXAMPLES |
78 | -------- | |
79 | ||
80 | To simply rebase `mybranch` onto `target`: | |
81 | ||
82 | ------------ | |
83 | $ git replay --onto target origin/main..mybranch | |
84 | update refs/heads/mybranch ${NEW_mybranch_HASH} ${OLD_mybranch_HASH} | |
85 | ------------ | |
86 | ||
22d99f01 EN |
87 | To cherry-pick the commits from mybranch onto target: |
88 | ||
89 | ------------ | |
90 | $ git replay --advance target origin/main..mybranch | |
91 | update refs/heads/target ${NEW_target_HASH} ${OLD_target_HASH} | |
92 | ------------ | |
93 | ||
94 | Note that the first two examples replay the exact same commits and on | |
95 | top of the exact same new base, they only differ in that the first | |
96 | provides instructions to make mybranch point at the new commits and | |
97 | the second provides instructions to make target point at them. | |
98 | ||
c4611130 EN |
99 | What if you have a stack of branches, one depending upon another, and |
100 | you'd really like to rebase the whole set? | |
101 | ||
102 | ------------ | |
103 | $ git replay --contained --onto origin/main origin/main..tipbranch | |
104 | update refs/heads/branch1 ${NEW_branch1_HASH} ${OLD_branch1_HASH} | |
105 | update refs/heads/branch2 ${NEW_branch2_HASH} ${OLD_branch2_HASH} | |
106 | update refs/heads/tipbranch ${NEW_tipbranch_HASH} ${OLD_tipbranch_HASH} | |
107 | ------------ | |
108 | ||
3916ec30 EN |
109 | When calling `git replay`, one does not need to specify a range of |
110 | commits to replay using the syntax `A..B`; any range expression will | |
111 | do: | |
112 | ||
113 | ------------ | |
114 | $ git replay --onto origin/main ^base branch1 branch2 branch3 | |
115 | update refs/heads/branch1 ${NEW_branch1_HASH} ${OLD_branch1_HASH} | |
116 | update refs/heads/branch2 ${NEW_branch2_HASH} ${OLD_branch2_HASH} | |
117 | update refs/heads/branch3 ${NEW_branch3_HASH} ${OLD_branch3_HASH} | |
118 | ------------ | |
119 | ||
120 | This will simultaneously rebase `branch1`, `branch2`, and `branch3`, | |
121 | all commits they have since `base`, playing them on top of | |
122 | `origin/main`. These three branches may have commits on top of `base` | |
123 | that they have in common, but that does not need to be the case. | |
124 | ||
f920b028 EN |
125 | GIT |
126 | --- | |
127 | Part of the linkgit:git[1] suite |