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

From: Jeff King <peff@peff.net>
Date: Jun 19, 2012, 20:12 UTC
Message-ID: <20120619201259.GB14692@sigill.intra.peff.net>
In-Reply-To: <7vipen191a.fsf@alter.siamese.dyndns.org>

On Tue, Jun 19, 2012 at 10:55:13AM -0700, Junio C Hamano wrote:

Show 23 quoted lines

> Marc Branchaud <marcnarc@xiplink.com> writes:
> 
> > On 12-06-18 06:12 PM, Junio C Hamano wrote:
> > ...
> >> 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.
> 
> I do not have a strong opinion either way, other than that I would
> prefer predictable behaviour over "works most of the time provided
> if the user does X, otherwise does this random thing".  And coming
> from that standpoint, erroring out when there needs a guess involved
> is certainly more predictable---it is a cop-out option for me in
> areas of the system I do not have strong preferences.

One thing that makes me nervous about this patch is that it is not just a change to git-submodule, but rather to git-parse-remote. So it could affect other parts of the system, too, where a guess might not be as desirable.

The number of affected code paths is fortunately quite small, since this is updating the shell library, and most of the remote-handling code is written in C these days. But it raises a few questions:

  1. git-pull can call into get_default_remote via get_remote_merge_branch.
     Is it impacted by this change?

  2. We install git-parse-remote as part of the plumbing API. Do we know
     of any other 3rd-party scripts that use this interface and might be
     affected?

  3. The C code sets up remote.c:default_remote_name, which defaults to
     "origin". Should this be consistent with what git-parse-remote
     does?

Should this be a submodule-only thing?

-Peff