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

Am 19.06.2012 16:07, schrieb Marc Branchaud:

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

quoted

Marc Branchaud [off-list ref] writes:

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.

And the "submodule add" documentation clearly talks about relative
submodule URLs being relative to the superproject's origin.

Your buildbot could also check if an origin is configured and use the
magic in your patch to configure one to the URL of the first remote it
finds if it isn't before initializing the submodules.

quoted

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.

Hmm, but guessing and using the first remote it finds (which might or
might not be the one used in the initial clone) doesn't sound like a
terribly good idea.

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.

Is there a way to reliably tell that remote without relying e.g. on
the implementation details of git config (e.g. it could sort remotes
alphabetically some day)? What happens if someone changes the config
later? A lot of ambiguity here ...

And I think origin should always be the second choice if it exists,
the first being the remote configured for the checked out branch.
This gives the user the opportunity to say "Oh, I screwed up using
'git clone -o', let's set origin to the upstream repo". But should we
try to guess the remote the superproject was cloned from as third
option? I am not convinced.