Re: Re* [RFC PATCH 2/1] Make request-pull able to take a refspec of form local:remote
Eric Sunshine sunsh...@sunshineco.com writes: +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. Thanks. +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? Thanks for your careful reading. Will drop it. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Re* [RFC PATCH 2/1] Make request-pull able to take a refspec of form local:remote
Junio C Hamano gits...@pobox.com writes: Sorry for back-burnering this topic so long. I think the following does what you suggested in the message I am responding to. Now, hopefully the only thing we need is a documentation update and the series should be ready to go. ... and here it is, to be sanity checked before I queue the whole thing in 'next'. -- 8 -- 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 gits...@pobox.com --- 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. + +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 +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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Re* [RFC PATCH 2/1] Make request-pull able to take a refspec of form local:remote
On Wed, Mar 12, 2014 at 2:04 PM, Junio C Hamano gits...@pobox.com 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 gits...@pobox.com --- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Re* [RFC PATCH 2/1] Make request-pull able to take a refspec of form local:remote
Linus Torvalds torva...@linux-foundation.org writes:
Thinking some more about the tag_name issue, I realize that the other
patch (Make request-pull able to take a refspec of form
local:remote) broke another thing.
The first patch pretty-printed the local branch-name, removing refs/
and possibly heads/ from the local refname. So for a branch, it
would ask people to just pull from the branch-name, and for a tag it
would ask people to pull from tags/name, which is good policy. So if
you had a tag called for-linus, it would say so (using
tags/for-linus).
But the local:remote syntax thing ends up breaking that nice feature.
The old find_matching_refs would actually cause us to show the tags
part if it existed on the remote, but that had become pointless and
counter-productive with the first patch. But with the second patch,
maybe we should reinstate that logic..
Sorry for back-burnering this topic so long.
I think the following does what you suggested in the message I am
responding to.
Now, hopefully the only thing we need is a documentation update and
the series should be ready to go.
-- 8 --
Subject: request-pull: resurrect pretty refname feature
When asking to fetch/pull a branch whose name is B or a tag whose
name is T, we used to show the command to run as:
git pull $URL B
git pull $URL tags/T
even when B and T were spelled in a more qualified way in order to
disambiguate, e.g. heads/B or refs/tags/T, but the recent update
lost this feature. Resurrect it.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
git-request-pull.sh | 4 +++-
t/t5150-request-pull.sh | 8 +++-
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/git-request-pull.sh b/git-request-pull.sh
index 93b4135..b67513a 100755
--- a/git-request-pull.sh
+++ b/git-request-pull.sh
@@ -53,6 +53,8 @@ fi
local=${3%:*}
local=${local:-HEAD}
remote=${3#*:}
+pretty_remote=${remote#refs/}
+pretty_remote=${pretty_remote#heads/}
head=$(git symbolic-ref -q $local)
head=${head:-$(git show-ref --heads --tags $local | cut -d' ' -f2)}
head=${head:-$(git rev-parse --quiet --verify $local)}
@@ -124,7 +126,7 @@ git show -s --format='The following changes since commit %H:
are available in the git repository at:
' $merge_base
-echo $url $remote
+echo $url $pretty_remote
git show -s --format='
for you to fetch changes up to %H:
diff --git a/t/t5150-request-pull.sh b/t/t5150-request-pull.sh
index 2622057..75d6b38 100755
--- a/t/t5150-request-pull.sh
+++ b/t/t5150-request-pull.sh
@@ -216,8 +216,14 @@ test_expect_success 'pull request format' '
git request-pull initial $downstream_url tags/full ../request
)
request sed -nf fuzz.sed request.fuzzy
- test_i18ncmp expect request.fuzzy
+ test_i18ncmp expect request.fuzzy
+ (
+ cd local
+ git request-pull initial $downstream_url
tags/full:refs/tags/full
+ ) request
+ sed -nf fuzz.sed request request.fuzzy
+ test_i18ncmp expect request.fuzzy
'
test_expect_success 'request-pull ignores OPTIONS_KEEPDASHDASH poison' '
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Re* [RFC PATCH 2/1] Make request-pull able to take a refspec of form local:remote
On Wed, Jan 29, 2014 at 03:34:32PM -0800, Junio C Hamano wrote: The previous two steps were meant to stop promoting the explicit refname the user gave to the command to a different ref that points at it. Most notably, we no longer substitute a branch name the user used with a name of the tqag that points at the commit at the tip of s/tqag/tag/ -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Re* [RFC PATCH 2/1] Make request-pull able to take a refspec of form local:remote
On Wed, Jan 29, 2014 at 3:34 PM, Junio C Hamano gits...@pobox.com wrote: I am not yet doing the docs, but here is a minimal (and I think is the most sensible) fix to the If I asked a tag to be pulled, I used to get the message from the tag in the output---the updated code no longer does so problem. That was a complete oversight/bug on my part, due to just removing the tag_name special cases, not thinking about the tag message. Thinking some more about the tag_name issue, I realize that the other patch (Make request-pull able to take a refspec of form local:remote) broke another thing. The first patch pretty-printed the local branch-name, removing refs/ and possibly heads/ from the local refname. So for a branch, it would ask people to just pull from the branch-name, and for a tag it would ask people to pull from tags/name, which is good policy. So if you had a tag called for-linus, it would say so (using tags/for-linus). But the local:remote syntax thing ends up breaking that nice feature. The old find_matching_refs would actually cause us to show the tags part if it existed on the remote, but that had become pointless and counter-productive with the first patch. But with the second patch, maybe we should reinstate that logic.. Linus -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
