fix(resolver): accept abbreviated git commit SHAs in user specs#346
fix(resolver): accept abbreviated git commit SHAs in user specs#346
Conversation
`github:owner/repo#<short>` (and other git specs with an abbreviated hex commit) now install. `git_resolve_ref` returns the prefix unchanged because abbreviated commits aren't advertised as refs; `git_shallow_clone` already checks them out via `git checkout`, and its post-checkout `rev-parse HEAD` is now bubbled up so the resolver pins the canonical 40-character SHA in the lockfile. Reported in #345. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Greptile SummaryThis PR allows abbreviated git commit SHAs (≥7 hex chars) in dependency specs by passing them through Confidence Score: 5/5Safe to merge — logic is correct, edge cases are well-handled, and the previously flagged lower-bound mismatch was fixed in the current commit. No P0 or P1 issues found. The re-keying strategy in canonicalize_clone_dir correctly addresses the double-clone concern from prior review threads. Races are documented as best-effort and are consistent with the existing design. The lower bound of 7 is properly aligned between looks_hex and git_commit_matches. No files require special attention. Important Files Changed
Reviews (3): Last reviewed commit: "review: re-key git clone cache to canoni..." | Re-trigger Greptile |
`git_resolve_ref` accepted hex prefixes >= 4 chars while `git_commit_matches` only treats prefixes >= 7 chars as a match, so a 4-6 char prefix would clear the upfront gate and then trip the post-checkout verification with a confusing mismatch error. Bump both to 7 (git's own default `core.abbrev`). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 1655684. Configure here.
`git_shallow_clone` previously keyed its on-disk cache by the input `commit` string. When the resolver passed an abbreviated SHA from a user's package.json, the cache landed under that abbreviation; the installer then queried with the lockfile-pinned full SHA and missed the cache, re-cloning the same repo a second time. After the clone, if the input `commit` differs from the rev-parsed `head_sha`, atomically rename the cache directory to the canonical full-SHA path. Best-effort: a cross-FS rename, race against a concurrent caller that already wrote the canonical entry, or perms failure leaves the original path intact and the next call pays one extra clone. Smoke-tested: cold install with `github:collinstevens/vfs#0b6ea53` leaves exactly one cache dir keyed on the full 40-char SHA. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Summary
github:owner/repo#<short>(and other git specs that use an abbreviated hex commit) now install instead of erroring withaube requires a full 40-character SHA.Details
git_resolve_refpreviously rejected hex prefixes upfront becausegit ls-remoteonly advertises branches and tags, so an abbreviated commit SHA never matched. Butgit_shallow_clonealready checks abbreviated commits out fine viagit fetch+git checkout <prefix>. The fix is to let the prefix flow throughgit_resolve_refunchanged and recover the canonical full SHA from the post-checkoutgit rev-parse HEADthatgit_shallow_clonealready runs for verification.git_shallow_clonenow returns(PathBuf, String)where the second element is the 40-char HEAD SHA.resolve_git_sourceuses that to populateGitSource.resolved, so the lockfile pins the canonical form regardless of what the user wrote.Reported in #345.
Test plan
cargo test(workspace, all green)cargo clippy --all-targets -- -D warningscargo fmt --checkaube installonpackage.jsonwith"vfs": "github:collinstevens/vfs#0b6ea53"(abbreviated) → installs, lockfile pins0b6ea539609031977983f0b2393ebe81ee28c8ecaube installon the same with the full 40-char SHA → still installs🤖 Generated with Claude Code
Note
Medium Risk
Changes git ref resolution and clone caching semantics, which can affect reproducibility and cache reuse for git dependencies. Risk is mitigated by explicit HEAD verification and new tests covering abbreviated-SHA behavior.
Overview
Git dependencies now accept abbreviated commit SHAs.
git_resolve_refno longer errors on 7–39 char hex prefixes and instead passes them through forgit_shallow_cloneto resolve.Lockfile and cache are canonicalized to full SHAs.
git_shallow_clonenow returns(clone_dir, head_sha)fromrev-parse HEAD, the resolver writes that full SHA intoGitSource.resolved, and the clone cache directory is best-effort re-keyed from the abbreviated input to the canonical SHA to avoid re-cloning.Adds targeted tests for offline full-SHA resolution and prefix matching, and updates install-time git cloning call sites for the new return type.
Reviewed by Cursor Bugbot for commit 414f7bb. Bugbot is set up for automated code reviews on this repo. Configure here.