feat: added gitlab support, simplified version sorting with ls-remote
This allows for easier access to both GitHub and GitLab releases, without having to modify anything new.
It also simplifies sorting by using git ls-remote's built-in --sort functionality. Since not all projects strictly follow semver, attempts were made to normalize it, such as if there is no - between a patch version and rc, prerelease, etc. Additionally, it adds the --exit-code argument, which returns 2 if there are no filtered releases found - normally, it would return 0, indicating that it had successfully connected to the remote.
NOTE: this does require git >= 2.18.0, so that is checked for.
It also removes the -C - argument from the curl call, which was attempting to resume downloads, querying the server for the byte range to do so. This is not universally supported, and if the server doesn't support it, the download will fail.
Finally, where possible, it uses shell built-ins like parameter substitution over calling external commands. If this isn't possible, it minimizes the number of spawned subshells by combining commands rather than piping. This speeds up the asdf ecosystem as a whole, by minimizing syscalls.
@stephanGarland Hey mate, I appreciate the PR and your interest in helping with performance. I am a fan of using ls-remote, an under-utilised tool in the greater world of software.
From my prior research (https://github.com/asdf-vm/asdf/issues/511#issuecomment-689885454 not sure how much I trust it) our current min version for git in asdf core is 1.7.7.2 which has a latest release on 2012-10-17. 2.18 is from 2018-06-21, so we're losing ~6 years of git version support. It would be interesting to see data on version usage, like we get with iOs/macOs etc.
Ultimately, I think it would mostly be fine. In the case a user doesn't have that version, it would be good to have a sane fallback for sorting instead of just exiting.
At least for Debian, current stable is 2.30.2-1. Homebrew is 2.39.1.
I'm fine with an if branch to drop back to installed tools, though - maybe I can add a one-time only message (touch a file, and if it exists, don't show the message?) suggesting the user upgrade?
I would just log each time. Perhaps this is time to introduce the post-plugin-add callback into the template. I use it in https://github.com/jthegedus/asdf-gcloud to validate required dependencies and warn the user
If not that, I would just log every time.