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

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 19, 2012, 20:31 UTC
Message-ID: <7vzk7zyrfu.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20120619201259.GB14692@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 13 quoted lines

> On Tue, Jun 19, 2012 at 10:55:13AM -0700, Junio C Hamano wrote:
>
>> 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.

That is exactly what I meant when I said "to make everything ... in a consistent way, without breaking existing users who rely on the current behaviour" (emphasis on *everything*). Also, I was (and am) reasonably sure that no such acceptable change exists in the "guess harder and pick a remote randomly" direction. Rather, I suspect that a consistent solution would be to tighten things to error out when in doubt, and correct submodule codepath that blindly uses 'origin' without erroring out by mistake, if that is the case (if what Marc alluded to was true; I didn't check).

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

Which would mean that users of git-parse-remote will end up deviating further from the norm if we allow patches that head in this direction to continue. That is one more reason to reject it.

> ...
> Should this be a submodule-only thing?

I'd rather not have any "submodule-only" thing; that would give us one less inconsistency to worry about. As Jens and Heiko both seem to think "pick a remote randomly" is a bad approach, I am not so worried about this discussion breaking areas outside submodules.