[Fix] specify 'origin' remote name with git clone ... installs

[rivy]

I ran into this as an installation failure when installing nvm on a PC using some git configuration customizations.

Since git may be configured locally to use a non-'origin' default remote name, specify 'origin' as the remote name when cloning to get the expected local repo setup.

[ljharb]

Thanks, this is a great catch!

Unfortunately, i believe git didn't add this option until v2.29, and we currently only require git v1.7.10. Would there be an alternative approach where instead of hardcoding "origin", we derive the default remote name, and just use that throughout the install script?

[rivy]

Hmm.

To my knowledge, there is no real default remote after the repo is created. I don't believe git holds any special regard for 'origin', or any other remote, as a default (other than then as the default initial remote name). There's no configuration info that I've seen that makes any differentiation. If there is more than one remote, git remote just displays all of them in alpha order.

A couple of ways to deal with the issue that come to mind are just using the git ... command as amended in the PR followed by the original version as an alternate. From looking at the docs, I believe that prior to v1.1.0 with the '-o' option [ref: git/git@e6c310f], there was no way to clone a repo to anything other than the 'origin' remote. It looks like the configuration variable 'clone.defaultRemoteName' was added in v2.30.0 [ref: git/git@de9ed3e]. So, if command git clone "$(nvm_source)" --depth=1 --origin=origin "${INSTALL_DIR}" fails then command git clone "$(nvm_source)" --depth=1 "${INSTALL_DIR}" should always install the remote as 'origin'.

Then using command git clone "$(nvm_source)" --depth=1 --origin=origin "${INSTALL_DIR}" || command git clone "$(nvm_source)" --depth=1 "${INSTALL_DIR}" || { ... } should always set up the repo to have the remote 'origin' pointing at the expected URL.

Alternatively, the script could cd "${INSTALL_DIR" ; git remote rename $(git remote) origin immediately after the clone (without a --origin=origin flag). That should also work for any version and set up the remote 'origin' correctly. (git doesn't throw an error if you rename a remote to the same name.)

I think the first option is likely the better choice. It should work for any version, be localized to a single code location, and should always result in the expected 'origin' setup.

[rivy]

I pushed a modified version.

[ljharb]

git docs say Overrides clone.defaultRemoteName from the config. which suggests that git config clone.defaultRemoteName || echo origin would be the value to use?

[rivy]

git docs say Overrides clone.defaultRemoteName from the config. which suggests that git config clone.defaultRemoteName || echo origin would be the value to use?

Yep, but that's only really good at the time of initial cloning.

[ljharb]

ah, so you're saying that that would work for the initial clone, but wouldn't help with future git operations?

wouldn't we be able to assume that the default, if configured, is unlikely to change?

[rivy]

I added references and corrected the mentioned versions to my second post. And, in looking at them again, it looks like -o was added in v1.1.0 [ref: git/git@e6c310f], though I don't see the where --origin was added.

I could just simply change it to use -o origin and that would, I believe, fit the version restriction.

[rivy]

ah, so you're saying that that would work for the initial clone, but wouldn't help with future git operations?

wouldn't we be able to assume that the default, if configured, is unlikely to change?

If some user changed it, I think it's actually more likely to change in the future. And the change will be external and unknown as a change to the repo. I think that setting it up with the expected 'origin' name from the start is going to be much more robust. Much less likely that a user would go into the repo and rename it than rethinking the config choice.

Personally, I had 'main' for a while, then went with 'local' on my home PC because I have a lot of customized soft-forks.

But, I'm likely a 0.1%-er here (or even 0.001%-er 😄).

[ljharb]

alrighty, let's go with -o origin, and just hardcode it, then.

[ljharb]

Can there be any install tests that cover this?

[ljharb]

Suggested change

	|| command git clone "$(nvm_source)" --depth=1 "${INSTALL_DIR}" || {
	|| command git clone "$(nvm_source)" --depth=1 -o origin "${INSTALL_DIR}" || {

[rivy]

I'll just shrink it to the single command/line since at least -o origin looks like it'll work with the version restriction.

[ljharb]

The difference is that the first one suppresses stderr; it's intentional to have the command twice so that when it fails, it tries again and prints out stderr for debugging purposes.

[rivy]

Can there be any install tests that cover this?

Sure. I'll take a look at your tests and try to work up a something that fits.

I think I should be able to add something to install_nvm_from_git.

Are you testing with the minimum git version? I don't see that anywhere.

[ljharb]

No, git version is just an implicit requirement.

[ljharb]

@rivy can you please check the "allow edits" checkbox?

also, are you interested in completing this PR?

[0cjs]

Unfortunately, i believe git didn't add this option until v2.29, and we currently only require git v1.7.10.

This is not correct. git clone --origin was added in commit 98a4fef3f2, and released in v1.2.5. A comment above indicate that -o was added in v1.1.0; I've not confirmed that, but from the diff for 98a4fef3f2 it's clear that -o was already present when --origin was added.

So I don't see any Git version issues here.

So what is this patch waiting on? (I just ran into this, created a PR to fix it, and immediately found out that the bug has been known for more than a year.)

[ljharb]

That's great to hear.

Since it seems this PR was made from a fork that's not on the author's username (rivy-fix instead of rivy), I won't ever be able to rebase it, so I'll close this in favor of #3654.