[Fix] install.sh: Force remote name of cloned repo to be 'origin' #3654
Conversation
|
This is a duplicate of #3341, and can't land as-is for the same reason. |
|
It'd be great to add tests, perhaps inside https://github.com/nvm-sh/nvm/blob/2b5e53fcd57409e018b468fd05eebad06fbff3fa/test/install_script/install_nvm_from_git |
The script assumes that the name of the remote is `origin`, but this is not the case if the user has set `clone.defaultRemoteName` to another value in the ~/.gitconfig (or elsewhere in the configuration). Adding `-o origin` ensures that the remote will be called `origin` regardless of the `clone.defaultRemoteName` setting. Per PR nvm-sh#3341: - The minimum Git version this should work with is v1.7.10. (This is not documented in the repo itself; it's just an implicit requirement.) - The `--origin` option was added to `git clone` in commit 98a4fef3f2 which was released in v1.2.5. From the diff of that commit, the `-o` option was already available at that time. So this easily satisfies the above. - A comment in nvm-sh#3341 indicates that `-o` was added in v1.1.0. I've not verified this, but we probably don't need to track that down since by the above we're already well within requirements.
0cjs
force-pushed
the
dev/cjs/25i11/install-clone-remote-name
branch
from
2b6c9aa to
7c82abd
Compare
It would. I've just updated the commit message to bring in the version information from #3341 so that doesn't get lost in the depths of GitHub tickets. I'll should be able to look at the testing situation later today, or over the weekend at the latest. Depending on the difficulty, I may suggest it's better just to get the change in without waiting for proper automated tests if those will be difficult, since this change on the face of it can't break anything that's not already broken unless someone's using a truly ancient version of Git, but it's worth delaying slightly until we actually know what's involved with such a test. And there's also the issue of all the failing PR checks at least some of which seem clearly unrelated to this change; I have no idea what to do about that. But I think we at least want some idea of why they're happening before we e.g. decide to ignore them or whatever. |
|
The WSL changes are known; and the v0.40.0 failures are expected, so indeed it’s nothing you need to worry about. |
See the commit message(s) for details. (I avoid duplicating them here because the commit messages are being updated as we review.)
Feel free to change the commit message (or anything else) as necessary. The
[Fix]prefix is not mentioned in the "rest of the conventions" for commit messages, but seems to be what is used for similar things in previous commits.This has been tested manually on my personal machine, where I use
clone.defaultRemoteName. The automated tests against the current head ofmaster(make TEST_SUITE=fast test-bash) had some issues for me, including what looked like spurious failures; I assume that this is just my configuration.The CI tests below also appear to have unrelated issues, giving e.g.
sed: /etc/apt/sources.list: No such file or directoryon WSL.