Line 302/301 `printf "$SOURCE_STR"` is missing a trailing newline char,
while line 281/282 and 285/286 have their own new line char, so I just
remove the manually added newline char, and add it to the end of the
variable "$SOURCE_STR", so no more manually newline char needed there.
On SmartOS setups using 64 bits pkgsrc repositories, `nvm_get_arch`
would not handle pkg_info's output properly.
This would result in nvm not being to install any node binary when
running on SmartOS setups using a 64 bits pkgsrc repository.
This change fixes this problem, and fixes the tests suite on similar
setups.
git-describe was taught `--abbrev=0` in 1.5.0:
https://github.com/git/git/blob/master/Documentation/RelNotes/1.5.0.txt
git-describe was taught `--match` in 1.5.5:
https://github.com/git/git/blob/master/Documentation/RelNotes/1.5.5.txt
I don't see anything else potentially weird in here, so I think it is
safe to proclaim that the minimum git version required to run these
commands is 1.5.5.
Documenting this minimum version required here should help people debug
possible issues and help maintainers of this project understand the
impacts of modifying these commands in the future.
As suggested by @ljharb, this might be a little cleaner. I'm not
entirely sure, but in any case, it is consistent with the upgrade
instructions, so that is nice.
I recently upgraded my copy of nvm and I was disappointed to be dropped
in the .nvm directory at the end of it. I also didn't like having to
copy and paste two separate blocks of code into my terminal, because I
missed the second one the first time around and was left in a slightly
confusing state. So, I decided to make this easier by utilizing
subshells and moving all of the instructions into one code block in this
document. I think this will improve people's experience maintaining this
tool.
`git describe` will match the latest tags, regardless of what it looks
like. We can make this a little safer by adding a `--match` flag to
match tags that look like version tags. This allows the maintainers of
this repo to more safely add other types of tags if they so wish,
without causing people to install or upgrade to those versions.
I recently ran the upgrade instructions and I ended up with the version
I was already on. This happened because `git describe` describes a
commit using the most recent tag reachable from it. Since I already had
a tag checked out, it was describing the tag I had already checked out.
Thankfully, `git describe` accepts an optional commit-ish, which it will
use instead of what we have currently checked out. Testing this in my
terminal now gives me the latest tag on origin, which is what I am
interested in when updating to the latest version.
~/.nvm ❯❯❯ git describe --abbrev=0 --tags
v0.30.1
~/.nvm ❯❯❯ git describe --abbrev=0 --tags origin
v0.31.3
I also added it to the manual install instructions for consistency and
extra safety.
Jordan Harband