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.
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