Re: [PATCH] t5516-fetch-push: Correct misspelled pushInsteadOf

[Junio C Hamano <gitster@pobox.com>]

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?