Skip to content

Commit 204ea3c

Browse files
committed
Merge branch 'se/doc-checkout-ours-theirs' into maint
A "rebase" replays changes of the local branch on top of something else, as such they are placed in stage #3 and referred to as "theirs", while the changes in the new base, typically a foreign work, are placed in stage #2 and referred to as "ours". Clarify the "checkout --ours/--theirs". * se/doc-checkout-ours-theirs: checkout: document subtlety around --ours/--theirs
2 parents b083703 + f303016 commit 204ea3c

File tree

1 file changed

+15
-0
lines changed

1 file changed

+15
-0
lines changed

Documentation/git-checkout.txt

Lines changed: 15 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -120,6 +120,21 @@ entries; instead, unmerged entries are ignored.
120120
--theirs::
121121
When checking out paths from the index, check out stage #2
122122
('ours') or #3 ('theirs') for unmerged paths.
123+
+
124+
Note that during `git rebase` and `git pull --rebase`, 'ours' and
125+
'theirs' may appear swapped; `--ours` gives the version from the
126+
branch the changes are rebased onto, while `--theirs` gives the
127+
version from the branch that holds your work that is being rebased.
128+
+
129+
This is because `rebase` is used in a workflow that treats the
130+
history at the remote as the shared canonical one, and treats the
131+
work done on the branch you are rebasing as the third-party work to
132+
be integrated, and you are temporarily assuming the role of the
133+
keeper of the canonical history during the rebase. As the keeper of
134+
the canonical history, you need to view the history from the remote
135+
as `ours` (i.e. "our shared canonical history"), while what you did
136+
on your side branch as `theirs` (i.e. "one contributor's work on top
137+
of it").
123138

124139
-b <new_branch>::
125140
Create a new branch named <new_branch> and start it at

0 commit comments

Comments
 (0)