blob: 288c2430ba9297299e471dfc9f4f572421019c64 [file] [log] [blame]
iannucci@chromium.orgc050a5b2014-03-26 06:18:50 +00001git-rebase-update(1)
2====================
3
4NAME
5----
6git-rebase-update -
7include::_git-rebase-update_desc.helper.txt[]
8
9SYNOPSIS
10--------
11[verse]
stip@chromium.org74374f92015-09-10 23:47:24 +000012'git rebase-update' [-v | --verbose] [-n | --no-fetch] [-k | --keep-going]
iannucci@chromium.orgc050a5b2014-03-26 06:18:50 +000013
14DESCRIPTION
15-----------
16
17Brings all branches up-to-date with their tracking branches. This involves
18several phases:
19
20Preparation::
21 If you currently have a branch checked out, any changes on that branch are
22 'frozen' (See linkgit:git-freeze[1] for more detail). Additionally, the current
23 branch is recorded for the 'Restoration' phase later (see 'CONFIGURATION
24 VARIABLES' for details on `depot-tools.rebase-update.starting-branch`).
25
26Fetching::
27 All branches are examined to find their upstream references. The correct set
28 of git remotes is determined, and fetched accordingly. Note that if any
29 branches have a tag as their upstream, we are forced to pull all remotes.
30+
pgervais@chromium.orgb9f27512014-08-08 15:52:33 +000031Pass `--no-fetch` to skip this phase.
iannucci@chromium.orgc050a5b2014-03-26 06:18:50 +000032
33Rebasing::
34 All branches are rebased in topological order from roots (upstreams) to
35 leaves. Each branch is rebased from its marked merge-base (see 'CONFIGURATION
36 VARIABLES') to the branch tip on top of its parent branch. If the parent
37 branch is 'frozen' (see linkgit:git-freeze[1]), the branch will be rebased
38 onto the last non-freeze commit on the parent branch.
39+
40Things get interesting when there are merge conflicts on rebase. The *most
41common* cause for conflicts is when your branch has been committed to the
42upstream in squashed form, ala linkgit:git-squash-branch[1], which is what
43linkgit:git-cl[1] and the 'Commit Queue' will do. Because of that, `git
44rebase-update` will attempt to squash your conflicted branch to see if the
45squashed version applies cleanly to its upstream.
46+
47If it does not apply cleanly, then your original (non-squashed) branch will be
48left in mid-rebase and `git rebase-update` will exit. You can deal with this
49like any other conflicted rebase. When you're done, just `git rebase-update`
50again to pick up where you left off.
51
stip@chromium.org74374f92015-09-10 23:47:24 +000052If you'd like to rebase all rebaseable branches in one pass and manually process
53the unrebaseable ones later, use -k or --keep-going. Cleanup will not happen
54until all branches apply cleanly.
55
iannucci@chromium.orgc050a5b2014-03-26 06:18:50 +000056Cleanup::
57 Once all the branches have been rebased, any empty branches (i.e. branches
58 with no commits on them) are removed. If a branch is removed in this fashion,
59 any branches which depend on it are reparented to the parent of the removed
60 branch (see linkgit:git-reparent-branch[1]).
61
62Restoration::
63 `git rebase-update` checks out the branch that you started on, and 'thaws' it,
64 if necessary (see linkgit:git-thaw[1]). If the branch you started on got
65 cleaned up, `git rebase-update` will checkout the 'root' ref (defaults to
66 'origin/master', as configured by `depot-tools.upstream`, see
67 linkgit:git-new-branch[1]).
68
69
70OPTIONS
71-------
72
Daniel McArdle43c083d2019-05-03 18:02:45 +000073-k::
74--keep-going::
75 Keep processing past failed rebases.
76
iannucci@chromium.orgc050a5b2014-03-26 06:18:50 +000077-n::
pgervais@chromium.orgb9f27512014-08-08 15:52:33 +000078--no-fetch::
iannucci@chromium.orgc050a5b2014-03-26 06:18:50 +000079 Skip the `git fetch` phase of rebase-update.
80
81-v::
82--verbose::
83 More text than your terminal can handle.
84
Daniel McArdle43c083d2019-05-03 18:02:45 +000085--current::
86 Only rebase the current branch.
87
iannucci@chromium.orgc050a5b2014-03-26 06:18:50 +000088
89CONFIGURATION VARIABLES
90-----------------------
91
92depot-tools.rebase-update.starting-branch
93~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
94
95When `git rebase-update` first runs, it will record the current branch here so
96that when it completes successfully, it will return back to the same branch you
97started on, even if `git rebase-update` is interrupted due to rebase conflicts.
98When `git rebase-update` completes successfully, this configuration variable is
99removed.
100
101branch.<name>.dormant
102~~~~~~~~~~~~~~~~~~~~~
103
104If `true`, will cause rebase-update to skip all processing on the branch.
105Useful for old/high-conflict branches which you want to keep for posterity, but
106don't want to deal with when running `git rebase-update`
107
108branch.<name>.base
109~~~~~~~~~~~~~~~~~~
110
111Holds the 'base' reference for this branch. By default this is equivalent to
112`git merge-base <name> <name>@{upstream}`. However, it can diverge if
113`<name>@{upstream}` is manually rebased. In this case, it correctly preserves
114the value it had before, where `git merge-base` would now report the wrong
115value.
116
117All of the tools in the linkgit:depot_tools[1] suite collude to keep this value
118as up-to-date as possible, including linkgit:git-reparent-branch[1], and
119linkgit:git-new-branch[1]. linkgit:git-map[1] also shows the location of these
120marker values in [black-background white]**white**.
121
122linkgit:git-mark-merge-base[1] allows easy manual interaction for this value,
123in the unlikely event that it gets out of sync.
124
125include::_aliases.txt[]
126
127----
128[alias]
129 git reup = rebase-update
130----
131
132
133SEE ALSO
134--------
135linkgit:git-new-branch[1], linkgit:git-reparent-branch[1],
136linkgit:git-rename-branch[1], linkgit:git-upstream-diff[1],
137linkgit:git-freeze[1], linkgit:git-mark-merge-base[1]
138
139include::_footer.txt[]
140
141// vim: ft=asciidoc: