[PATCH] Documentation/git-pull: clarify configuration

[PATCH] Documentation/git-pull: clarify configuration

[Martin von Zweigbergk]

The sentence about 'branch.<name>.rebase' refers to the first sentence
in the paragraph. Clarify by moving it right after that sentence.

Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
---
 Documentation/git-pull.txt |   11 +++++------
 1 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt
index c50f7dc..e9c0393 100644
--- a/Documentation/git-pull.txt
+++ b/Documentation/git-pull.txt
@@ -92,12 +92,11 @@ 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 a merge, perform a rebase after fetching. To make this
+	the default for branch `<name>`, set configuration
+	`branch.<name>.rebase` to `true`. 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.
 +
 [NOTE]
 This is a potentially _dangerous_ mode of operation.
-- 
1.7.3.2.167.ga361b

Re: [PATCH] Documentation/git-pull: clarify configuration

[Jonathan Nieder]

Martin von Zweigbergk wrote:

> The sentence about 'branch.<name>.rebase' refers to the first sentence
> in the paragraph. Clarify by moving it right after that sentence.

Sane.

> --- a/Documentation/git-pull.txt
> +++ b/Documentation/git-pull.txt
> @@ -92,12 +92,11 @@ 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 a merge, perform a rebase after fetching. To make this
> +	the default for branch `<name>`, set configuration
> +	`branch.<name>.rebase` to `true`.

Grammatically, the narrator first gives an order to the git program
("perform a rebase") and then to the person configuring it ("set the
configuration").  Maybe it would be clearer to focus on what the
program does in this case?

	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)).

When is a patch ready for inclusion? (Re: [PATCH] Documentation/git-pull: clarify configuration)

[Jonathan Nieder]

(cc-ing the list because it seems likely the wording could be improved)

Hi Martin,

Martin von Zweigbergk wrote:

> I don't want to spam Junio, so I'm asking you instead. I sent my first
> version of the patch to Junio as well. In SubmittingPatches, it says
> "[...] the maintainer (gitster@pobox.com) if (and only if) the patch
> is ready for inclusion". How do I know if it's ready for inclusion?

I think that bit is not too important.  The idea (and it isn't spelled
out) is that you should Cc Junio if:

 - you need Junio's advice because it is his area of expertise, or
 - Junio has already been discussing the patch with you, or
 - it is urgent that the patch be applied

and you probably should not Cc Junio if:

 - the patch is unpolished and covers a subject that is not his
   interest (e.g., something in contrib/)

>                                                               Or is the
> "ready for inclusion" just about my perception of my patches?

Yes.  Hopefully this would make it easier to spot which patches are
ready for his attention and which need more discussion first.  See [1]
and [2].

Hope that helps,
Jonathan

[1] http://thread.gmane.org/gmane.comp.version-control.git/72432/focus=72442
[2] http://thread.gmane.org/gmane.comp.version-control.git/144199/focus=144506