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

From: Phil Hord <phil.hord@gmail.com>
Date: Jun 20, 2012, 02:49 UTC
Message-ID: <CABURp0oF8YE2f_a-xLdzM4x5XFdoaJtKCFd-njSdv9g9N_TEzA@mail.gmail.com>
In-Reply-To: <4FE0F264.1040703@xiplink.com>

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 <marcnarc@xiplink.com> wrote:

Show 27 quoted lines

>
> On 12-06-19 03:41 PM, Jens Lehmann wrote:
> > Am 19.06.2012 16:07, schrieb Marc Branchaud:
> >> On 12-06-18 06:12 PM, Junio C Hamano wrote:
> >>> Marc Branchaud <marcnarc@xiplink.com> 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.
>
> 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.

Show 13 quoted lines

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

Show 8 quoted lines

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

Show 29 quoted lines

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

Show 20 quoted lines

>
> > 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'"?
>
> > 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