Junio C Hamano venit, vidit, dixit 16.01.2013 16:50:
> Michael J Gruber <g...@drmicha.warpmail.net> writes:
>> Junio C Hamano venit, vidit, dixit 15.01.2013 16:53:
>> ...
>>>  * 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...

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