From: Thomas Rast <trast@student.ethz.ch>
Date: Sun, 15 Nov 2009 21:11:10 GMT
Subject: Re: [PATCH 2/3] rebase docs: clarify --merge and --strategy
Message-ID: <200911152211.11928.trast@student.ethz.ch>
In-Reply-To: <7v7htrfqi1.fsf@alter.siamese.dyndns.org>

Junio C Hamano wrote:
> diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
> index e802421..a6f8182 100644
> --- a/Documentation/git-rebase.txt
> +++ b/Documentation/git-rebase.txt
> @@ -229,9 +229,11 @@ OPTIONS
>  	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>.
> +Note that a rebase merge works by replaying each commit from the working
> +branch on top of the <upstream> branch.  Because of this, when a merge
> +conflict happens, the side reported as 'ours' is the so-far rebased
> +series, starting with <upstream>, and 'theirs' is the working branch.  In
> +other words, the sides are swapped.

This is much nicer than mine!

> -Due to the peculiarities of 'git-rebase' (see \--merge above), using
> +Because 'git-rebase' replays each commit from the working branch
> +on top of the <upstream> branch using the given strategy,
> +(see \--merge above), using
>  the 'ours' strategy simply discards all patches from the <branch>,
>  which makes little sense.  Thus 'git-rebase' does not accept this
>  strategy.

Here I'm not sure if it makes such a big difference, since we already
explained the problem in --merge (and point to it).  But yours is fine
too.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch