[jsegaran]

Builds on #134, which builds on #130. Review only the last commit, 1ed860f. Merge after #134.

In a shallow repository, X^ / X~n step past a boundary that git stops at. gix's rev_parse walks the parents the commit object names. When another fetch has brought a boundary commit's parent into the object store, gix resolves base^ to it, while git reports unknown revision:

git fetch --depth 1 $src base:refs/heads/base
git fetch $src old:refs/heads/old       # old is base's parent
git rev-parse base^                     # fatal: unknown revision
yas RESOLVE base^                       # -> old

The same applies to X~n, to ranges such as old..base^, and to LOG specs, which go through RESOLVE.

In a shallow repository, resolve_one now rewrites each range endpoint of the form <rev> followed only by ^n/~n steps. It resolves <rev> with gix, walks the steps itself, and replaces the endpoint with the resulting commit. A step off a commit listed in .git/shallow is NotFound. ^0 stays put, ^n takes the nth parent, and ~n follows first parents. Other forms (^@/^!, which #134 handles; :path; @{…} on its own) still go straight to gix. Repositories that are not shallow are untouched.

parent_steps_stop_at_a_shallow_boundary builds that clone. It expects base^, base~1, head~2 and old..base^ to be NotFound, and head^ and head~1^0 to resolve to base. Before this commit, base^ resolves to old.

Found by differential fuzzing of RESOLVE in shallow clones.

cargo test -p yas-git --test engine, cargo clippy -p yas-git --all-targets -- -D warnings and cargo fmt --check pass.

Tag @indent to continue the conversation here.