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

[Junio C Hamano <gitster@pobox.com>]

Michael J Gruber <git@drmicha.warpmail.net> writes:

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

That is not necessarily true, depending on the definition of your
"same".  Having multiple URLs/PushURLs that refer to physically
different locations, as long as "git push there" immediately
followed by "git fetch here" should work with the repositories that
are conceptually equivalent, is a supported mode of operation. In
fact, they being physically different _was_ the original motivation
of the feature. See 755225d (git builtin "push", 2006-04-29).

The definition of the "immediate" above also depends on your use; it
could be tens of minutes (you may be fetching from git.k.org that
can be reached from the general public, which may be a cname for
multiple machines mirroring a single master.k.org that k.org account
holders push to, and there may be propagation delays).  In such a
scenario, your URL may point at the public git.k.org, pushURL may
point at master.k.org, and you may have other pushURLs that point at
other places you use as back-up locations (e.g. git.or.cz or
github.com).

As long as you _mean_ to maintain their contents the same, you can
call them conceptually "the same repo" and your statement becomes
true.

> It never was meant to push to several repos.

This is false.  It _was_ designed to be used that way from day one.
(I am not saying using it in other ways is an abuse---I am merely
saying that pushing to multiple physically different repositories is
within its scope).

> That being said, I don't mind changing the behaviour of set-url.

I do not think we want to change the behaviour of set-url.  What
needs to be fixed is the output from "remote -v".  It should:

 * When there is no pushURL but there is a URL, then show it as
   (fetch/push), and you are done;

 * When there is one or more pushURLs and a URL, then show the URL
   as (fetch), and show pushURLs as (push), and you are done;

 * When there are more than one URLs, and there is no pushURL, then
   show the first URL as (fetch/push), and the remainder in a
   notation that says it is used only for push, but it shouldn't be
   the same "(push)"; the user has to be able to distinguish it from
   the pushURLs in a repository that also has URLs.

 * When there are more than one URLs, and there are one or more
   pushURLs, then show the first URL as (fetch), the other URLs
   as (unused), and the pushURLs as (push).

Strictly speaking, the last one could be a misconfiguration.  If you
have:

	[remote "origin"]
        	url = one
                url = two
                pushurl = three
                pushurl = four

then your "git fetch" will go to one, and "git push" will go to
three and four, and two is never used.

It should also be stressed that the third one a supported
configuration.  With

	[remote "origin"]
        	url = one
                url = two

your "git fetch" goes to one, and your "git push" will go to one and
two.  This is the originally intended use case of 755225d.  It is to
push to and fetch from master.k.org (think of "one" above) and in
addition to push to backup.github.com ("two").