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

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 15, 2013, 15:53 UTC
Message-ID: <7v4nii5tp2.fsf@alter.siamese.dyndns.org>
In-Reply-To: <50F524F8.5090803@drmicha.warpmail.net>

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