-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Faster clone method #22
Comments
This sounds like a great idea, and for long term storage of repos would also help us known when it's time to pull again. |
Seems I also suggest that we clone from scratch for each crate version: #14
We already have sha1 from the downloaded crate |
I've meant searching tags for crates that lack sha1 from cargo, usually due to having a "dirty" directory when publishing. |
Another related idea might be abusing the git-sha1 hash in the git tree objects to avoid having to fetch and hash each file. This would be relying on the known cyptographically broken sha1, so maybe this defeats the whole point of a tool like this, but it would certainly improve speed and reduce disk usage. For example for this repo:
Here we can see that the hash of the deny.toml matches. We could walk both trees and compare all files. A downside would be no way to compare the differences. If there's a mismatch, you'd likely want to request the sources from the git forge anyway to compare the differences. |
Instead of cloning the repo and then looking for a tag, you can use
git ls-remote
(Remote::create_detached
&connect_auth
&list
in git2) to find a tag and its sha1.When you have a sha1, you can init an empty repo, and do
git fetch +3db7c05aa35749cc4e0f0f892bc5831219901f98:refs/heads/whateverbranch --depth=1
to get just that one commit.The text was updated successfully, but these errors were encountered: