Junio C Hamano [off-list ref] writes:
Jardel Weyrich [off-list ref] writes:
quoted
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.
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 [off-list ref]
Subject: Re: [BUG] Possible bug in `remote set-url --add --push`
Date: Sat, 12 Jan 2013 06:09:35 -0200
Message-ID: [off-list ref]
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.
Junio C Hamano venit, vidit, dixit 15.01.2013 07:39:
Junio C Hamano [off-list ref] writes:
quoted
Jardel Weyrich [off-list ref] writes:
quoted
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 [off-list ref]
Subject: Re: [BUG] Possible bug in `remote set-url --add --push`
Date: Sat, 12 Jan 2013 06:09:35 -0200
Message-ID: [off-list ref]
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.