On 14/01/2013, at 17:09, Junio C Hamano <gits...@pobox.com> wrote:

> Michael J Gruber <g...@drmicha.warpmail.net> writes:
>> It seems to me that everything works as designed, and that the man page
>> talk about "push URLs" can be read in two ways,...
> Hmph, but I had an impression that Jardel's original report was that
> one of the --add --pushurl was not adding but was replacing.  If
> that was a false alarm, everything you said makes sense to me.
> Thanks.

I failed to explain my reasoning. But I learned quite a bit from this 
discussion. I understood that the defaul push url is not used by git-push when 
there's at least one pushurl for a given remote.

If that's by design, I still fail to comprehend the exact reason.
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.

This is exactly what I thought to be a bug. If it's intended to work the way I 
described in the previous scenario, I'll have to ask and/or research to 
understand the reason behind this -- Why does having a pushurl make git-push 
_not_ to push to the default push location (the 1st repo in my scenario) as 
well? Could you describe a scenario in which that behavior is useful and/or 
better than the behavior I expected?

Please, pardon me for not being as clear as needed. I appreciate your time on 
this. Thank you all.

Sent from my mobile.--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to