[New] Speedup process to install nvm from git by dropping commit history

[PeterDaveHello]

Speed up the installation and bandwidth and save almost 50% disk space in v0.33.1:
2304KB ./nvm-origin-install
1296KB ./nvm-new-install

[ljharb]

I really dislike the --depth command in git; there seems to be no way to later obtain the rest of the commits - in other words, the repo checked out with this command is permanently crippled.

Is this incorrect?

[PeterDaveHello]

Nope, that's wrong, you can use git fetch --unshallow to get the history, and of course you can also fetch other branches or tags to get what you want, I don't think there is a need for end user to get the whole history.

[ljharb]

What happens if I have a preexisting repository, and we do a fetch of depth 1 - what happens to the, say, 50 commits in between?

[PeterDaveHello]

@ljharb before you did a git gc, the objects will still remain here, just won't display in the history as where you're fetching, so for example if you have 50 commits history already, this will reduce your history to only 1 commit, but I think this is not a problem for developer since I won't use the script to upgrade nvm, will only use it for first time installation, and as we know that there are some users with not so powerful platform may have a little bit performance issue and overhead on their disk, this can also help a little bit I think, anyway, my point is that the enduser don't need a history by default, right?

[ljharb]

ok so you're saying that with --depth, fetch is a destructive operation?

[PeterDaveHello]

not really, it's about how git working, git fetch won't delete data IMO, it just fetch a reference point with certain history depth, and when the referenced commits not exist, it'll grab them, if it's already exist, they'll just be there.

[ljharb]

I've never used --depth, so sorry for needing lots of explanation :-)

Let's say I have commits 1 through 50 locally, the remote has 150, and I do a fetch with --depth=50. Do I have 1-50 and 100-150 locally now? Or do I only appear to have 100-150? Or does --depth only work on clone?

[PeterDaveHello]

@ljharb it works on both clone and fetch, if it have 50 last commits locally on a certain branch/tag and you fetch with --depth=50 no matter how many commits in remote, you'll still have the latest 50 commits on the target branch/tag, and might not be the origin 50 commits since the remote may already moved forward for 100 commits or something like that, but if you don't do git gc to compress and clean up the local repository, the origin commits in the tag/branch are still trace-able by git log <sha1>, git show <sha1> etc.

To be more clear here, as we don't delete the old tags, the old versions won't be deleted by this change, the only difference is - if the user wants to see the log of a certain tagged version/commit, git will only show up the last commit in that version/tag, and this won't affect the user anything about nvm using, as most of the users are just users, they don't need to trace the nvm code history, if they need to have a development environment, and they found that the history will be needed(actually they don't even need the history to development nvm, I don't think everyone traces code), then they can clone a clean repo or we can help them unshallow the history, but anyway I don't think it's a common case, as you can see there are tons of users of nvm but only about 200 contributors and most of the contributors will have a few commits.

[PeterDaveHello]

btw, I tested it via a full installation, and it looks ... super light and fast now! Even on a slow computer! You can try it:

curl -Lo- https://github.com/PeterDaveHello/nvm/raw/aba5e75b3d0f5b0d697d93f5a58f73913244c8f1/install.sh | bash

as the history are dropped, the git gc process in the progress is super fast now! Maybe, this is even the better way to make the repo files smaller but not git gc to solve the too many files on fs problem haha ... (I think you remember the reason why I added git gc :) )

[PeterDaveHello]

Even on a fast enough computer, install into ramdisk (/run/shm on linux, export NVM_DIR="/run/shm/.nvm" before the installation), the origin installation took about 233% time to install then the optimized version:

time curl -Lo- https://github.com/PeterDaveHello/nvm/raw/aba5e75b3d0f5b0d697d93f5a58f73913244c8f1/install.sh | bash:

real    0m5.650s
user    0m2.180s
sys     0m0.137s

time curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.33.1/install.sh | bash:

real    0m13.208s
user    0m7.887s
sys     0m0.367s

[ljharb]

So if I git show the oldest commit in a chunk, does the parent commit just not exist on my local machine?

I think I understand that the original commits would be present but unreachable, and thus candidates for GC - and that git fetch --unshallow would fill in the gaps.

[PeterDaveHello]

The parent commit won't be there, unless it's just one of the tagged releases or you did a git fetch with --unshallow or deeper --depth

[ljharb]

Gotcha.

OK, so I think this is ready to go :-) but, I'm going to wait until a few days after the next release before merging, since this release is pretty big already.

[PeterDaveHello]

Personally I think we can save the disk space and bandwidth just from now, as it's not a big at all, won't make a big release that bigger, but it's up to you, I'm just waiting for the next release.

[PeterDaveHello]

@ljharb is there anything else I can do here? Thanks.

[ljharb]

If we can resolve the --fail issues in master, I'll merge this prior to the next release.

[PeterDaveHello]

I think you mean another fixed issue?

[ljharb]

I'm referring to #1562, fixed by #1567.

[PeterDaveHello]

Okay, we're on the same page, as that's not caused by --fail 😄