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

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 15, 2013, 06:22 UTC
Message-ID: <7vpq1755jb.fsf@alter.siamese.dyndns.org>
In-Reply-To: <1D472234-A0A5-4F02-878D-D05DEE995FCD@gmail.com>

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.