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

Junio C Hamano venit, vidit, dixit 16.01.2013 16:50:

Michael J Gruber [off-list ref] writes:

quoted

Junio C Hamano venit, vidit, dixit 15.01.2013 16:53:
...

quoted

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

Maybe "(fetch fallback/push)" if we do use it as a fallback? If we don't
we probably should?

I actually think my earlier "it shouldn't be the same (push)" is not
needed and probably is actively wrong.  Just like you can tell
between

    (only one .url)                     (both .url and .pushurl)

    origin there (fetch/push)           origin there (fetch)
                                        origin there (push)

even when the value of the URL/PushURL, i.e. "there", is the same
between .url and .pushurl, you should be able to tell between

    (two .url, no .pushurl)             (one .url and one .pushurl)

    origin there (fetch/push)           origin there (fetch)
    origin another (push)               origin another (push)

So let's not make it too complex and forget about the different kind
of "(push)".

A case that is a potential misconfiguration would look like:

    (two .url, one .pushurl)

    origin there (fetch)
    origin some  (unused)
    origin another (push)

I think.

I'm sorry but E_NOPARSE. I can't grok the above at all. But I'll try
again tomorrow ;)

In any case, the issue with (push)instead of that John mentions bothers
me: there are "two specified URLs" but one URL in config only; my patch
doesn't make that case clearer at all. My early attempts at amending
struct remote produced too many segfaults to continue today...

Michael