Thread (3 messages) flat view 3 messages, 3 authors, 2016-06-15

Re: [PATCH] Clarify documentation on the "ours" merge strategy.

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:47:42

Thomas Rast [off-list ref] writes:
quoted hunk
I'd much rather see this explained in the description of the rebase
-m/-s options since it (the swap) applies to all uses of 'git rebase
-m'.  Perhaps with an extra (but short) note in the "ours"
description, like so:
diff --git i/Documentation/git-rebase.txt w/Documentation/git-rebase.txt
index 33e0ef1..181947c 100644
--- i/Documentation/git-rebase.txt
+++ w/Documentation/git-rebase.txt
@@ -228,6 +228,10 @@ 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>::
diff --git i/Documentation/merge-strategies.txt w/Documentation/merge-strategies.txt
index 4365b7e..0cae1be 100644
--- i/Documentation/merge-strategies.txt
+++ w/Documentation/merge-strategies.txt
@@ -33,6 +33,9 @@ ours::
 	merge is always the current branch head.  It is meant to
 	be used to supersede old development history of side
 	branches.
++
+Because the sides in a rebase are swapped, using this strategy with
+git-rebase is never a good idea.
 
 subtree::
 	This is a modified recursive strategy. When merging trees A and
Looking very good.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help