git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Michael J Gruber <git@drmicha.warpmail.net>
Date
Jan 15, 2013, 09:44 UTC
Message-ID
<50F524F8.5090803@drmicha.warpmail.net>
In-Reply-To
<7vip6z54rh.fsf@alter.siamese.dyndns.org>
Junio C Hamano venit, vidit, dixit 15.01.2013 07:39:
Show 51 quoted lines
> 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.
Show 18 quoted lines
> 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.
> 
Previous: Junio C HamanoNext: Junio C Hamano
Message 13 of 27 in “[BUG] Possible bug in `remote set-url --add --push`”
  1. Jardel WeyrichJan 12, 2013
  2. Junio C HamanoJan 12, 2013
  3. Jardel WeyrichJan 12, 2013
  4. Junio C HamanoJan 12, 2013
  5. Sascha CunzJan 12, 2013
  6. Jardel WeyrichJan 12, 2013
  7. Michael J GruberJan 14, 2013
  8. Jonathan NiederJan 14, 2013
  9. Junio C HamanoJan 14, 2013
  10. Jardel WeyrichJan 15, 2013
  11. Junio C HamanoJan 15, 2013
  12. Junio C HamanoJan 15, 2013
  13. Michael J GruberJan 15, 2013
  14. Junio C HamanoJan 15, 2013
  15. Michael J GruberJan 16, 2013
  16. Junio C HamanoJan 16, 2013
  17. Michael J GruberJan 16, 2013
  18. Andreas SchwabJan 16, 2013
  19. Junio C HamanoJan 16, 2013
  20. git-remote: distinguish between default and configured URLsMichael J Gruber, Jan 16, 2013
  21. Michael J GruberJan 16, 2013
  22. John KeepingJan 16, 2013
  23. Michael J GruberJan 16, 2013
  24. John KeepingJan 16, 2013
  25. Junio C HamanoJan 16, 2013
  26. Phil HordJan 16, 2013
  27. Michael J GruberJan 16, 2013

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.