Marc Branchaud <marcnarc@xxxxxxxxxxx> writes: > On 12-06-18 01:33 PM, Junio C Hamano wrote: >> marcnarc@xxxxxxxxxxx writes: >> >>> From: Marc Branchaud <marcnarc@xxxxxxxxxxx> >>> >>> 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. > 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. 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? -- 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