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

[Marc Branchaud <marcnarc@xiplink.com>]

On 12-06-18 06:12 PM, Junio C Hamano wrote:
> 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.

Erroring out seems like a step backwards to me.  Things already work just
fine when the remote the user wants is called "origin".

I suppose you could say that I'm arguing for a better default remote than
"origin".

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

I think git can do better than erroring out, though.

> It is OK that your build usesdetached HEAD, but if that is the case
> shoudln't it be the one deciding which specific remote it wants to
> take the updated sources from, and telling Git to do so?

Sure, but I feel it did that already when it cloned.  It seems reasonable for
the submodules to default to using the remote specified when the super-repo
was cloned.

		M.