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]

 



Marc Branchaud <marcnarc@xxxxxxxxxxx> 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.

If you can work with submodule people (it is good that you Cc'ed
Jens) to come up with a solution to make everything always use
'origin' when unconfigured in a consistent way, without breaking
existing users who rely on the current behaviour, that would be
good.  Or a solution with a predictable behaviour you come up with
may end up being something more involved than "just use 'origin'
when you do not know". As long as the end result can be easily
explained to end users, I wouldn't have any objection.

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