Skip to content

Commit

Permalink
Merge branch 'se/doc-checkout-ours-theirs'
Browse files Browse the repository at this point in the history
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
  • Loading branch information
gitster committed Aug 3, 2015
2 parents 2bf2d81 + f303016 commit c0b901e
Showing 1 changed file with 15 additions and 0 deletions.
15 changes: 15 additions & 0 deletions Documentation/git-checkout.txt
Original file line number Diff line number Diff line change
Expand Up @@ -120,6 +120,21 @@ entries; instead, unmerged entries are ignored.
--theirs::
When checking out paths from the index, check out stage #2
('ours') or #3 ('theirs') for unmerged paths.
+
Note that during `git rebase` and `git pull --rebase`, 'ours' and
'theirs' may appear swapped; `--ours` gives the version from the
branch the changes are rebased onto, while `--theirs` gives the
version from the branch that holds your work that is being rebased.
+
This is because `rebase` is used in a workflow that treats the
history at the remote as the shared canonical one, and treats the
work done on the branch you are rebasing as the third-party work to
be integrated, and you are temporarily assuming the role of the
keeper of the canonical history during the rebase. As the keeper of
the canonical history, you need to view the history from the remote
as `ours` (i.e. "our shared canonical history"), while what you did
on your side branch as `theirs` (i.e. "one contributor's work on top
of it").

-b <new_branch>::
Create a new branch named <new_branch> and start it at
Expand Down

0 comments on commit c0b901e

Please sign in to comment.