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

[Michael J Gruber <git@drmicha.warpmail.net>]

Junio C Hamano venit, vidit, dixit 16.01.2013 16:50:
> Michael J Gruber <git@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...

Michael