Re: [PATCH 2/3] rebase docs: clarify --merge and --strategy
- From
Thomas Rast <trast@student.ethz.ch>
- Date
- Nov 15, 2009, 21:11 UTC
- Message-ID
- <200911152211.11928.trast@student.ethz.ch>
- In-Reply-To
- <7v7htrfqi1.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
Show 16 quoted lines
> 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!
Show 7 quoted lines
> -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