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

On 12-06-18 06:12 PM, Junio C Hamano wrote:

Marc Branchaud [off-list ref] writes:

quoted

On 12-06-18 01:33 PM, Junio C Hamano wrote:

quoted

marcnarc@xiplink.com writes:

quoted

From: Marc Branchaud <redacted>

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

quoted

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.