From: Michael J Gruber <git@drmicha.warpmail.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: Anders Kaseorg <andersk@mit.edu>, git@vger.kernel.org
Subject: Re: [PATCH] t5516-fetch-push: Correct misspelled pushInsteadOf
Date: Wed, 04 Mar 2015 10:36:13 +0100 [thread overview]
Message-ID: <54F6D20D.903@drmicha.warpmail.net> (raw)
In-Reply-To: <xmqq8ufdc0c7.fsf@gitster.dls.corp.google.com>
Junio C Hamano venit, vidit, dixit 03.03.2015 21:06:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
>
>> Junio C Hamano venit, vidit, dixit 02.03.2015 20:43:
>>> Anders Kaseorg <andersk@mit.edu> writes:
>>>
>>>> Signed-off-by: Anders Kaseorg <andersk@mit.edu>
>>>> ---
>>>> t/t5516-fetch-push.sh | 2 +-
>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh
>>>> index 85c7fec..594d7a6 100755
>>>> --- a/t/t5516-fetch-push.sh
>>>> +++ b/t/t5516-fetch-push.sh
>>>> @@ -238,7 +238,7 @@ test_expect_success 'push with pushInsteadOf' '
>>>> test_expect_success 'push with pushInsteadOf and explicit pushurl (pushInsteadOf should not rewrite)' '
>>>> mk_empty testrepo &&
>>>> test_config "url.trash2/.pushInsteadOf" testrepo/ &&
>>>> - test_config "url.trash3/.pusnInsteadOf" trash/wrong &&
>>>> + test_config "url.trash3/.pushInsteadOf" trash/wrong &&
>>>> test_config remote.r.url trash/wrong &&
>>>> test_config remote.r.pushurl "testrepo/" &&
>>>> git push r refs/heads/master:refs/remotes/origin/master &&
>>>
>>> Interesting.
>>>
>>> Now an obvious and natural question after seeing this change is how
>>> the original test passed with misspelled configuration. Is a test
>>> that pushes into "trash/wrong" checking the right outcome? If the
>>> reason why the existing tests passed without this patch is because
>>> they do not test the right thing, then shouldn't they be corrected
>>> together with the above fix?
>>>
>>
>> Ha, I was look there, too, just today and was wondering the same.
>>
>> I guess the test wanted to make sure (among other things) that
>> url.trash3/.pushInsteadOf does not affect the push to remote r (which
>> has an explicit pushurl)...
>
> OK, so it makes sure the push goes to testrepo/ but it does not make
> sure trash2 or trash3 are not touched. Makes sort of sense.
>
> Thanks.
>
> I am not sure how the intention of the commit 1c2eafb8 (Add
> url.<base>.pushInsteadOf: URL rewriting for push only, 2009-09-07),
> which introduced the behaviour verified by this test, interacts with
> the desire to redefine what URL and pushURL mean in our recent past,
> what e.g. e6196ae1 (remote: add --fetch and --both options to set-url,
> 2014-11-25) wanted to do, though. Thoughts?
>
Wow. That looks strange to me on first read. Sorry I didn't catch it
back then. "--fetch" sets both url and pushurl??
Also, talking about these things (in the commit msg etc.) can be
confusing very quickly because there are the config names url and
pushurl, the struct members url und pushurl, and then suddenly the
notion of "fetch URL" appears.
So, for definiteness sake, I'll use "url" and "pushurl" for the config
names and struct members (which the config values end up in), and I'll
use "URL for fetch" and "URL for push" for the URLs that git will use
for fetch resp. push.
If there is no "pushurl":
"url" will be used as the "URL for fetch" and as the "URL for push".
if we are pushing and there is "pushinsteadof" for (part of) "url"
subsitute that within "url"
else if there is "insteadof" for (part of) "url"
substitute that within "url"
If there is a "pushurl":
"url" will be used as the "URL for fetch" and "pushurl" as the "URL
for push".
if we are pushing and there is "insteadof" for (part of) "pushurl"
substitute that within "pushurl"
else if we are fetching and there is "insteadof" for (part of) "url"
substiute that within "url"
I don't know what "remote set-url" does, I think the whole remote
command as it is does not fit in well with our UI, but that applies to
other commands with non-option subcommands as well (or bad). I would
have hoped it is set-url and set-pushurl to set those two config
options. Maybe that's not useful.
The logic above may look a bit strange regarding pushinsteadof, but it's
really what makes this useful. An example:
[url "git://github.com/"]
insteadOf = github:
[url "github:"]
pushinsteadOf = github:
This allows me to use
git remote add <remotename> github:<user>/<reponame>
and have fetches over git protocol, pushes over ssh since my ssh_config has:
host github
Hostname github.com
User git
IdentityFile ~/.ssh/repoor_dsa
[url "https://bitbucket.org/"]
insteadOf = bitbucket:
[url "https://grubix@bitbucket.org/"]
pushinsteadOf = bitbucket:
This allows me to use
git remote add <remotename> bitbucket:<user>/<reponame>
and have fetches over https, pushes over https with my username preset.
I rarely use pushurl, but could use it to override url, or to do the
above magic on a case by case level, such as if I need to specify
different usernames for the same host.
So, that's my understanding of how these things are supposed to work and
why it is useful.
Michael
next prev parent reply other threads:[~2015-03-04 9:43 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-01 4:18 [PATCH] t5516-fetch-push: Correct misspelled pushInsteadOf Anders Kaseorg
2015-03-02 19:43 ` Junio C Hamano
2015-03-03 15:51 ` Michael J Gruber
2015-03-03 20:06 ` Junio C Hamano
2015-03-04 9:36 ` Michael J Gruber [this message]
2015-03-04 9:43 ` Anders Kaseorg
2015-03-04 10:10 ` Michael J Gruber
2015-03-04 20:14 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54F6D20D.903@drmicha.warpmail.net \
--to=git@drmicha.warpmail.net \
--cc=andersk@mit.edu \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.