Thomas Rast <trast@xxxxxxxxxxxxxxx> writes: > 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html