From: Marc Branchaud Date: Tue, 19 Jun 2012 14:07:19 GMT Subject: Re: [PATCH] Try harder to find a remote when on a detached HEAD or non-tracking branch. Message-ID: <4FE08797.50509@xiplink.com> In-Reply-To: <7vmx402rru.fsf@alter.siamese.dyndns.org> On 12-06-18 06:12 PM, Junio C Hamano wrote: > Marc Branchaud writes: > >> On 12-06-18 01:33 PM, Junio C Hamano wrote: >>> marcnarc@xiplink.com writes: >>> >>>> From: Marc Branchaud >>>> >>>> get_default_remote() tries to use the checked-out branch's 'remote' config >>>> value to figure out the remote's name. This fails if there is no currently >>>> checked-out branch (i.e. HEAD is detached) or if the checked-out branch >>>> doesn't track a remote. In these cases and the function would just fall >>>> back to "origin". >>>> >>>> Instead, let's use the first remote listed in the configuration, and fall >>>> back to "origin" only if we don't find any configured remotes. >>> >>> I admit that I wouldn't do anything that relies on any remote to be >>> used while on detached head myself, so in that sense I am a biased >>> audience, but guessing (or not guessing and blindly assuming >>> 'origin') feels wrong, and trying even harder to come up with an >>> even wilder guess feels even more wrong. >> >> OK, but what would be right? AFAIK git doesn't have any real way of >> designating an official default remote. > > Correct, and that is why I tend to think "right" is to error out. Erroring out seems like a step backwards to me. Things already work just fine when the remote the user wants is called "origin". I suppose you could say that I'm arguing for a better default remote than "origin". >> That would be bad for our situation. As I said, our automated build system >> uses detached HEADs a lot. Erroring-out in this case would break us. It's >> really only the near-ubiquity of the name "origin" that has kept things >> working so far. > > 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. M.