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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jeff King <peff@xxxxxxxx> writes:

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

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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]