On 14-05-29 06:42 PM, Junio C Hamano wrote: > While it is not *wrong* per-se to say that pulling a rewound/rebased > branch will lead to an unnecessary merge conflict, that is not what > the leading "+" sign to allow non-fast-forward update of remote-tracking > branch is at all. > > Signed-off-by: Junio C Hamano <gitster@xxxxxxxxx> > --- > Documentation/pull-fetch-param.txt | 18 +++++++++--------- > 1 file changed, 9 insertions(+), 9 deletions(-) > > diff --git a/Documentation/pull-fetch-param.txt b/Documentation/pull-fetch-param.txt > index 18cffc2..2a7e2b7 100644 > --- a/Documentation/pull-fetch-param.txt > +++ b/Documentation/pull-fetch-param.txt > @@ -24,15 +24,15 @@ is updated even if it does not result in a fast-forward > update. > + > [NOTE] > -If the remote branch from which you want to pull is > -modified in non-linear ways such as being rewound and > -rebased frequently, then a pull will attempt a merge with > -an older version of itself, likely conflict, and fail. > -It is under these conditions that you would want to use > -the `+` sign to indicate non-fast-forward updates will > -be needed. There is currently no easy way to determine > -or declare that a branch will be made available in a > -repository with this behavior; the pulling user simply > +When the remote branch you want to fetch is known to > +be rewound and rebased regularly, it is expected that > +the tip of it will not be descendant of the commit that > +used to be at its tip the last time you fetched it and > +stored in your remote-tracking branch. You would want I think the second part of that last sentence might be clearer as it is expected that its new tip will not be a descendant of its previous tip (as stored in your remote-tracking branch the last time you fetched). Then start the next sentence with In this case, you would want .... M. > +to use the `+` sign to indicate non-fast-forward updates > +will be needed for such branches. There is no way to > +determine or declare that a branch will be made available > +in a repository with this behavior; the pulling user simply > must know this is the expected usage pattern for a branch. > + > [NOTE] > -- 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