Am 19.06.2012 16:07, schrieb Marc Branchaud: > On 12-06-18 06:12 PM, Junio C Hamano wrote: >> Marc Branchaud <marcnarc@xxxxxxxxxxx> writes: >>> 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. >> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html