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

I mostly want to say "Amen, brother", so if you are not interested in
a me-too, then feel free to skip this reply.

On Tue, Jun 19, 2012 at 5:43 PM, Marc Branchaud [off-list ref] wrote:

On 12-06-19 03:41 PM, Jens Lehmann wrote:

quoted

Am 19.06.2012 16:07, schrieb Marc Branchaud:

quoted

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.

This whole thing seems a bit weird...

So user A adds a submodule with <repository> "../others/thing.git".
 Clearly
user A has some remote in mind when they added this submodule.

But consider user B, who cloned the super-repo from the same remote that
user
A had in mind when creating the submodule.  If user B then checks out a
non-tracking branch (or a branch that tracks a different remote) and then
tries to initialize/update the submodule, user B will get an error.

This specific situation is what makes me think that picking any
arbitrary remote should work in most cases.  I think this is why
picking 'origin' works just fine now, except in the special case of
"no remote named origin and no tracking branch".  If I'm using
relative urls, I've got to have my associated submodules available at
each remote I might push to or clone from.  Otherwise I'm just
shooting my feet for fun.

To me this is clearly wrong.  It's also wrong to error-out and expect the
user to fix it.  Should the user temporarily set their branch's remote to
the
right place, initialize the submodule, then undo the branch setting?
 Should
the user check our a branch that tracks the correct remote, initialize the
submodule, then check out their branch?  Both of those "solutions" look
pretty weak to me.

I'm starting to think that maybe "git submodule init" (and "update")
should
learn a --remote option.  That way at least user B could tell git what to
do.

I like this one.

quoted

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.

Yes, it seems my assumptions about how to determine the default remote
shouldn't be coded into git.  But dang it, the current fallback to
"origin"
is really lame.

Amen!

I also think the assumption of "same as the current tracking branch"
is lame, too.  (But I have to admit, it works better than 95% of the
time, and it's easier than erroring out.  If it works for Apple, it
should work here.)

quoted

quoted

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.

Fair enough, but I still think it's better than guessing that the right
remote is "origin".  :)

quoted

quoted

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

Yes, I agree.

Should there perhaps be some kind of "cloned from this remote" setting in
the
config?

I'm not sure I like the "give preference to my original clone source"
idea.  Who said it could be king? What if it was temporary and I've
since moved on to a new server? Well, yeah, I can reconfigure my
default.  So I guess I do like it a little.

quoted

And I think origin should always be the second choice if it exists,
the first being the remote configured for the checked out branch.

Do you mean "the origin(al) remote repository" or just "the remote named
'origin'"?

quoted

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.

Maybe I'm misinterpreting you.  Are you attaching a special meaning to a
remote named "origin"?

               M.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html