It is a bit misleading to show the status of the last published version, because some issues could have been already resolved and this is not clear at a first glance.

Feel free to close this PR if the current behavior is intended.

Your tag heuristics doesn't work for the crate utf8parse. It is part of a larger workspace. The correct tag to use is utf8parse_v0.2.1 not v0.2.1 (which refers to the containing project vte I believe). This is part of https://github.com/alacritty/vte

It should be possible to use something like rayon to run many checks of different dependencies in parallel. The program doesn't seem to be either CPU or network bound, so it should be trivial to make it go faster.

Using --filter=blob:none still clones tags, but avoids downloading blobs until they are needed, e.g. until particular revision of the repository is checked out.

Cloning all blobs including large deleted files may take a lot of space for some repositories.

If this Boolean environment variable is set to false, git will not prompt on the terminal (e.g., when asking for HTTP authentication).

As explained by the git docs this prevents private or deleted repositories from blocking the clone process by asking for credentials. Unfortunately, this doesn't seem to stop git from prompting about ssh key authenticity.

Beware that it's possible to have a tarball with cargo.toml that will be readable as Cargo.toml on a case-insensitive file system, but will not match path == "Cargo.toml" check in Rust.

Due to case-insensitivity confusion, cargo package can behave differently on macOS and Windows where it may end up with both README.md and Readme.md or an extra cargo.lock: https://github.com/rust-lang/cargo/issues/13722

Unfortunately there's a bunch of old crates affected by this.

https://github.com/rust-lang/crates.io/issues/8410

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.

It is easy to create commit somewhere off the main branch where nobody reviews it. Some projects keep non-main branch as default or maintain multiple stable branches that contain backports and are never merged into main, but at least a warning would be nice.

I also wonder if we can do something to prevent (re)moving tags later. If we check published crate today and tag is in the right place, it can still be moved later. Can we do something to prevent it? I have looked a bit into annotated tags, but it does not seem to be possible to merge the tag into branch, i.e. make it impossible to remove the tag without force-pushing, right?

I can see hash of annotated tags in .git/packed-refs, and it is different from the hash of the commit annotated tag points to, but attempting to merge this into main branch results in merging the commit, git says there is nothing to do, "already merged".

In mercurial it is different, tags are stored in .hgtags file that is actually commited to the branch. This means tags look different depending on the commit checked out, but they are permanently recorded in the history. Is there anything similar for git? It seems to be at least possible to extend git this way, nothing prevents writing .gittags into the repo.

cargo-goggles needs a way to store a list of tested reproducible and tested non-reproducible crates next to Cargo.lock so it can be committed to the repository. Then in CI we can check that all packages from Cargo.lock have been tested and are included in one of these lists. Locally developers can run cargo-goggles to update the list, but likely not in CI on every commit because downloading git repositories for all dependencies is too slow and uses git hoster resources unnecessarily.

This will fix "Make it pull previously cloned repositories when changes are available" todo item from the readme. Together with #13 this should be relatively cheap to clone the same repo multiple times.

Having a separate checkout for each crate makes everything easier because each repository is cloned and checked out once and is not changed afterwards.