On Wed, Nov 10, 2010 at 12:37 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Martin von Zweigbergk <martin.von.zweigbergk@xxxxxxxxx> writes:
>
>> diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt
>> index c50f7dc..055126e 100644
>> --- a/Documentation/git-pull.txt
>> +++ b/Documentation/git-pull.txt
>> @@ -92,12 +92,15 @@ include::merge-options.txt[]
>> :git-pull: 1
>>
>> --rebase::
>> - Instead of a merge, perform a rebase after fetching. If
>> - there is a remote ref for the upstream branch, and this branch
>> - was rebased since last fetched, the rebase uses that information
>> - to avoid rebasing non-local changes. To make this the default
>> - for branch `<name>`, set configuration `branch.<name>.rebase`
>> - to `true`.
>> + Instead of merging, rebase the current branch on top of the
>> + upstream branch after fetching. If there is a remote-tracking
>> + branch corresponding to the upstream branch and the upstream
>> + branch was rebased since last fetched, the rebase uses that
>> + information to avoid rebasing non-local changes.
>> +
>> + The default behavior is to merge rather than rebasing, but it
>> + can be overridden per branch with the `branch.<name>.rebase`
>> + configuration item (see git-config(1)).
>
> The explanation looks correct in the sense that it does not say anything
> incorrect, and the description of non-local change exclusion in the first
> paragraph is more readable, I think.
>
> But I am not sure if we want a separate paragraph here only to repeat a
> half of what the second paragraph in the DESCRIPTION section already said.
> The "default is merge" is implied by "Instead of merging" at the beginnig
> of this part anyway.
>
> Also have you tried to actually format this and checked the result before
> submitting the patch?
>
> Perhaps doing it like this may be better (no I didn't run AsciiDoc on it).
>
>
> --rebase::
> Rebase the current branch on top of the upstream branch after
> fetching. If there is a remote-tracking branch corresponding to
> the upstream branch and the upstream branch was rebased since last
> fetched, the rebase uses that information to avoid rebasing
> non-local changes.
> +
> See `branch.<name>.rebase` in linkgit:git-config[1] if you want to make
> `git pull` always use `{litdd}rebase` instead of merging.
I'm happy with either your suggestion or Jonathan's. Do you want me to
send an updated patch to the list or will you make the change directly?
While writing a reply to another message, I happened to spot a similar
problem in the documentation for 'git rebase -s'. It currently says "Use
the given merge strategy. If there is no -s option git merge-recursive
is used instead. This implies --merge." and I assume the last sentence
refers to the first one in this case too. Same question here: Should I
send a patch?
--
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