regex: use regexec_buf()
[gitweb.git] / Documentation / git-checkout.txt
index 63b739c550dda6fddb73fad776d48e0b71f71bfa..5e5273e073c351a3c845043a69916a1773cefd94 100644 (file)
@@ -107,6 +107,12 @@ OPTIONS
 --quiet::
        Quiet, suppress feedback messages.
 
+--[no-]progress::
+       Progress status is reported on the standard error stream
+       by default when it is attached to a terminal, unless `--quiet`
+       is specified. This flag enables progress reporting even if not
+       attached to a terminal, regardless of `--quiet`.
+
 -f::
 --force::
        When switching branches, proceed even if the index or the
@@ -120,6 +126,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