Re: [PATCH] Try harder to find a remote when on a detached HEAD or non-tracking branch.

> Marc Branchaud <marcnarc@xiplink.com> writes:
> 
>> On 12-06-18 01:33 PM, Junio C Hamano wrote:
>>> marcnarc@xiplink.com writes:
>>>
>>>> From: Marc Branchaud <marcnarc@xiplink.com>
>>>>
>>>> get_default_remote() tries to use the checked-out branch's 'remote' config
>>>> value to figure out the remote's name.  This fails if there is no currently
>>>> checked-out branch (i.e. HEAD is detached) or if the checked-out branch
>>>> doesn't track a remote.  In these cases and the function would just fall
>>>> back to "origin".
>>>>
>>>> Instead, let's use the first remote listed in the configuration, and fall
>>>> back to "origin" only if we don't find any configured remotes.
>>>
>>> I admit that I wouldn't do anything that relies on any remote to be
>>> used while on detached head myself, so in that sense I am a biased
>>> audience, but guessing (or not guessing and blindly assuming
>>> 'origin') feels wrong, and trying even harder to come up with an
>>> even wilder guess feels even more wrong.
>>
>> OK, but what would be right?  AFAIK git doesn't have any real way of
>> designating an official default remote.
> 
> Correct, and that is why I tend to think "right" is to error out.

>> That would be bad for our situation.  As I said, our automated build system
>> uses detached HEADs a lot.  Erroring-out in this case would break us.  It's
>> really only the near-ubiquity of the name "origin" that has kept things
>> working so far.
> 
> That reliance of "origin" is what made me think that "not guessing
> and blindly assuming" a wrong thing to do.