On Wed, Mar 12, 2014 at 2:04 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Subject: [PATCH] request-pull: documentation updates
>
> The original description talked only about what it does. Instead,
> start it with the purpose of the command, i.e. what it is used for,
> and then mention what it does to achieve that goal.
>
> Clarify what <start>, <url> and <end> means in the context of the
> overall purpose of the command.
>
> Describe the extended syntax of <end> parameter that is used when
> the local branch name is different from the branch name at the
> repository the changes are published.
>
> Signed-off-by: Junio C Hamano <gitster@xxxxxxxxx>
> ---
> Documentation/git-request-pull.txt | 55 +++++++++++++++++++++++++++++++++-----
> 1 file changed, 49 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/git-request-pull.txt b/Documentation/git-request-pull.txt
> index b99681c..57bc1f5 100644
> --- a/Documentation/git-request-pull.txt
> +++ b/Documentation/git-request-pull.txt
> @@ -13,22 +13,65 @@ SYNOPSIS
> DESCRIPTION
> -----------
>
> -Summarizes the changes between two commits to the standard output, and includes
> -the given URL in the generated summary.
> +Prepare a request to your upstream project to pull your changes to
> +their tree to the standard output, by summarizing your changes and
> +showing where your changes can be pulled from.
Perhaps splitting this into two sentence (and using fewer to's) would
make it a bit easier to grok? Something like:
Generate a request asking your upstream project to pull changes
into their tree. The request, printed to standard output,
summarizes the changes and indicates from where they can be
pulled.
> +The upstream project is expected to have the commit named by
> +`<start>` and the output asks it to integrate the changes you made
> +since that commit, up to the commit named by `<end>`, by visiting
> +the repository named by `<url>`.
> +
>
> OPTIONS
> -------
> -p::
> - Show patch text
> + Include patch text in the output.
>
> <start>::
> - Commit to start at.
> + Commit to start at. This names a commit that is already in
> + the upstream history.
>
> <url>::
> - URL to include in the summary.
> + The repository URL to be pulled from.
>
> <end>::
> - Commit to end at; defaults to HEAD.
> + Commit to end at (defaults to HEAD). This names the commit
> + at the tip of the history you are asking to be pulled.
> ++
> +When the repository named by `<url>` has the commit at a tip of a
> +ref that is different from the ref you have it locally, you can use
Did you want to drop "it" from this sentence? Or did you mean to say
"the ref as you have it locally"?
> +the `<local>:<remote>` syntax, to have its local name, a colon `:`,
> +and its remote name.
> +
> +
> +EXAMPLE
> +-------
> +
> +Imagine that you built your work on your `master` branch on top of
> +the `v1.0` release, and want it to be integrated to the project.
> +First you push that change to your public repository for others to
> +see:
> +
> + git push https://git.ko.xz/project master
> +
> +Then, you run this command:
> +
> + git request-pull v1.0 https://git.ko.xz/project master
> +
> +which will produce a request to the upstream, summarizing the
> +changes between the `v1.0` release and your `master`, to pull it
> +from your public repository.
> +
> +If you pushed your change to a branch whose name is different from
> +the one you have locally, e.g.
> +
> + git push https://git.ko.xz/project master:for-linus
> +
> +then you can ask that to be pulled with
> +
> + git request-pull v1.0 https://git.ko.xz/project master:for-linus
> +
>
> GIT
> ---
> --
> 1.9.0-293-gd838d6f
--
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