marcnarc@xiplink.com writes:
From: Marc Branchaud <redacted>
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.
Shouldn't we be erroring out instead?
On 12-06-18 01:33 PM, Junio C Hamano wrote:
marcnarc@xiplink.com writes:
quoted
From: Marc Branchaud <redacted>
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. It seems to me that the first one in
the config is actually better than just using "origin". At least, that
remote seems very likely to be the one used when the repo was cloned.
Shouldn't we be erroring out instead?
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.
But we finally ran into a situation where someone used "git clone -o", and
that seems to have broken relative-path submodules in some situations. (I
would not be at all surprised if "git clone -o" breaks an assortment of other
features, too. I think there are a few places in the code where "origin" is
presumed to be a valid remote name, and also the one the user wants to use.)
M.