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

Jeff King [off-list ref] writes:

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

quoted

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.