Closed SamuraiAku closed 5 months ago
Short of cloning every repository and then running
git log --pretty="%H %T" | grep <tree-hash>
There's no way to get a commit hash.
You could use the command git ls-remote
to get a list of all current tags and confirm that the tag exists, which should be true for the vast majority of packages out there.
For those packages that don't use TagBot, the best option may be to use the tree hash in the DownloadLocation, even though that's not exactly proper. And then include git instructions in the Package comments on how to convert that tree hash into a commit. Or maybe put the tree hash in the comments along with the instructions? Think about this some more.
With some more research into how Pkg does this, here's what I got
There's no way to get around cloning the repository. Once you've done that it's possible to checkout with the tree hash using
git checkout <tree_hash> .
The period is important (referring to the top of the repository) in order for git to figure out you're referring to a tree hash and not a commit hash and updating all the files.
Another good command that won't need a difference between tree and commit hash is:
git archive <tree_hash> . --output=<path to tree_archive.tar>
Put a note about this into the package comments so a reader is hopefully not confused if they try to checkout the tree hash as if it's a commit.
Today when filling in the Package Download Location, we provide a tag that assumes that everyone uses TagBot when releasing a package to the public. That's very common but isn't universally true.
To be completely accurate, we would have to take the git-tree-sha1 (which is not the git commit) and use LibGit to contact the repository, search it for a matching tree hash and then find a git commit that points to it.
Julia does this all the time to download packages, at least to the point of finding the tree hash. But how is it done?