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

> 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