Martin von Zweigbergk [off-list ref] writes:
quoted hunk
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.
On Wed, Nov 10, 2010 at 12:37 PM, Junio C Hamano [off-list ref] wrote:
Martin von Zweigbergk [off-list ref] writes:
quoted
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?
Martin von Zweigbergk wrote:
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?
Yes, please!
In general, carefully written patches that improve the documentation
are always welcome. (And sloppy patches are not so bad, either.)