Re: [BUG] Possible bug in `remote set-url --add --push`

[Michael J Gruber <git@drmicha.warpmail.net>]

Junio C Hamano venit, vidit, dixit 15.01.2013 07:39:
> Junio C Hamano <gitster@pobox.com> writes:
> 
>> Jardel Weyrich <jweyrich@gmail.com> writes:
>>
>>> If you allow me, I'd like you to forget about the concepts for a minute, and focus on the user experience.
>>> Imagine a simple hypothetical scenario in which the user wants to push to 2 distinct repositories. He already has cloned the repo from the 1st repository, thus (theoretically) all he needs to do, is to add a new repository for push. He then uses `remote set-url --add --push <2nd-repo>` (which I personally thought would suffice). However, if he tries to push a new commit to this remote, it would be pushed _only_ to the 2nd-repo.
>>
>> The primary reason behind push-url was that
>>
>>  (1) usually you push to and fetch from the same, so no pushUrl is
>>      ever needed, just a single Url will do (this is often true for
>>      cvs/svn style shared repository workflow); and
>>
>>  (2) sometimes you want to fetch from one place and push to another
>>      (this is often true for "fetch from upstream, push to my own
>>      and ask upstream to pull from it" workflow), and in that case
>>      you want pushUrl in addition to Url.  Most importantly, in this
>>      case, you do *NOT* want to push to Url.  You only push to
>>      pushUrl.
>>
>> Setting *one* pushURL is a way to say "That URL I fetch from is
>> *not* the place I want to push (I may not even be able to push
>> there); when I say 'push', push there instead".  Your proposed
>> semantics will make it impossible to arrange such an asymmetric
>> setting.
> 
> Now I think I finally see where that misunderstanding comes from.
> It is "remote -v" that is misdesigned.
> 
>     $ git clone ../there here
>     $ cd here
>     $ git remote -v
>     origin /var/tmp/there (fetch)
>     origin /var/tmp/there (push)
> 
> This is totally bogus.  It should report something like this:
> 
>     $ git remote -v
>     origin /var/tmp/there (fetch/push)
> 
> Then after running "git remote set-url --push origin ../another" we
> should see
> 
>     $ git remote -v
>     origin /var/tmp/there (fetch)
>     origin /var/tmp/another (push)
> 
> which would make it clear that the original fetch/push came from the
> (1) usuall you push and fetch from the same place so there is only
> one setting, and the two lines came from the (2) sometimes you need
> a separate places to fetch from and push to.

Yes, that is one big source of misunderstanding. Cleaning up remote -v
would help, along with the man page.

Also there is a conceptual confusion: pushurl is meant to push to the
same repo using a different url, e.g. something authenticated
(https/ssh) for push and something faster/easier for fetch.

It never was meant to push to several repos. That is what "remotes" are
for, and it would help if we could push to a remote group (which is
difficult because of refspecs etc.) easily.

That being said, I don't mind changing the behaviour of set-url.

> At this point, if you say "set-url --push origin ../third", then
> "another" will disappear and gets replaced by "third"; if you
> instead say "set-url --add --push origin ../third", then we will see
> two (push) lines, in addition to one (fetch), making it clear that
> you are still in (2) above, fetching from and pushing to different
> places, and having two places to push to.
> 
> I misread your response
> 
>     From: Jardel Weyrich <jweyrich@gmail.com>
>     Subject: Re: [BUG] Possible bug in `remote set-url --add --push`
>     Date: Sat, 12 Jan 2013 06:09:35 -0200
>     Message-ID: <CAN8TAOvP_HX6BEK86aYoX-kVqWDmsbyptxTT2nk+fx+Ut1Tojg@mail.gmail.com>
> 
> where you showed that there was only remote.origin.url (and no
> pushurl) in the first step, and somehow thought you had a
> remote.origin.pushurl in the first place.
>