Junio C Hamano venit, vidit, dixit 15.01.2013 07:39: > Junio C Hamano <gitster@xxxxxxxxx> writes: > >> Jardel Weyrich <jweyrich@xxxxxxxxx> 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@xxxxxxxxx> > 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@xxxxxxxxxxxxxx> > > 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. > -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html