[PATCH 2/3] rebase docs: clarify --merge and --strategy
- From
Thomas Rast <trast@student.ethz.ch>
- Date
- Nov 15, 2009, 18:25 UTC
- Message-ID
- <b7f805f2497d748b685544b64cd91a36c3bdf5d6.1258309432.git.trast@student.ethz.ch>
- In-Reply-To
- <cover.1258309432.git.trast@student.ethz.ch>
Add a paragraph about the swapped sides in a --merge rebase, which was otherwise only documented in the sources.
Add a paragraph about the effects of the 'ours' strategy to the -s description. Also remove the mention of the 'octopus' strategy, which was copied from the git-merge description but is pointless in a rebase.
Signed-off-by: Thomas Rast <trast@student.ethz.ch> --- Documentation/git-rebase.txt | 13 ++++++++++--- 1 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt index 33e0ef1..5fa9100 100644 --- a/Documentation/git-rebase.txt +++ b/Documentation/git-rebase.txt @@ -228,13 +228,20 @@ OPTIONS Use merging strategies to rebase. When the recursive (default) merge strategy is used, this allows rebase to be aware of renames on the upstream side. ++ +Note that in a rebase merge (hence merge conflict), the sides are +swapped: "theirs" is the to-be-applied patch, and "ours" is the so-far +rebased series, starting with <upstream>. -s <strategy>:: --strategy=<strategy>:: Use the given merge strategy. - If there is no `-s` option, a built-in list of strategies - is used instead ('git-merge-recursive' when merging a single - head, 'git-merge-octopus' otherwise). This implies --merge. + If there is no `-s` option 'git-merge-recursive' is used + instead. This implies --merge. ++ +Due to the peculiarities of 'git-rebase' (see \--merge above), using +the 'ours' strategy simply discards all patches from the <branch>, +which makes little sense. -q:: --quiet::
-- 1.6.5.2.420.gf6c057.dirty