From 31ddd1ee0fdd0a03001994d362023a04d8231eb0 Mon Sep 17 00:00:00 2001 From: Thomas Rast Date: Sun, 15 Nov 2009 19:25:31 +0100 Subject: [PATCH] rebase docs: clarify --merge and --strategy 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 Signed-off-by: Junio C Hamano --- Documentation/git-rebase.txt | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt index 0aefc34d0..167c8bed5 100644 --- a/Documentation/git-rebase.txt +++ b/Documentation/git-rebase.txt @@ -228,13 +228,23 @@ 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 a rebase merge works by replaying each commit from the working +branch on top of the branch. Because of this, when a merge +conflict happens, the side reported as 'ours' is the so-far rebased +series, starting with , and 'theirs' is the working branch. In +other words, the sides are swapped. -s :: --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. ++ +Because 'git-rebase' replays each commit from the working branch +on top of the branch using the given strategy, using +the 'ours' strategy simply discards all patches from the , +which makes little sense. -q:: --quiet:: -- 2.30.2