How do you verify your first Crab push?

A progress bar only proves that Crab did some work. A verified push needs five visible results: Git stores a pointer, Crab publishes the branch, a fresh clone finds that pointer, hydration rebuilds the file, and the rebuilt bytes match the original.

1. Start from a clean test branch

Use a configured repository and keep this first test away from a shared production branch.

git status --short
crab doctor
export CRAB_VERIFY_REMOTE="$(git remote get-url origin)"
git switch -c verify-crab-push

If git status --short prints anything, commit or stash it first. Fix any crab doctor failure before creating test data.

The CRAB_VERIFY_REMOTE variable keeps the same remote URL for the fresh-clone check later. Run the tutorial in one shell so the variable remains available.

2. Create one file with a known hash

This sample is deliberately simple. It proves the storage path, not real-world deduplication performance.

mkdir -p models
dd if=/dev/zero of=models/checkpoint.bin bs=1048576 count=64
git hash-object models/checkpoint.bin > ../checkpoint.git-hash

git hash-object gives the file a repeatable content ID using Git's own hashing tool. Saving it outside the repository prevents the evidence file from entering the test commit.

Now route .bin files through Crab:

crab track '*.bin'
git add .gitattributes
git check-attr filter -- models/checkpoint.bin

The last command should report filter: crab. If it does not, stop here and fix the tracking rule.

3. Stage the file and inspect Git's copy

crab add models/checkpoint.bin
git show :models/checkpoint.bin

The output should be a short text pointer with a version, file-hash, and size. Your working-tree file remains 64 MiB; only Git's staged representation is small.

If git show emits binary data, do not commit it. The file missed the Crab filter.

4. Commit and publish

git commit -m "Verify first Crab push"
crab push

Step through the trace below. Crab uploads immutable Git and large-file data, verifies that the pointer can be reconstructed, and only then advances the branch.

Check the two commit IDs:

git rev-parse HEAD
git ls-remote origin refs/heads/verify-crab-push

The hashes should match. That proves the remote branch names your commit—but not yet that another client can reconstruct the file.

Run the repository checks:

crab status
crab fsck

crab status checks the tracked file's local state. crab fsck checks pointer, metadata, chunk, and remote-object relationships.

5. Prove it from a fresh clone

Leave the writer repository. Clone the test branch lazily so the new worktree starts with the pointer:

cd ..
crab clone --branch verify-crab-push "$CRAB_VERIFY_REMOTE" vision-search-verify
cd vision-search-verify
crab status

crab status should mark models/checkpoint.bin as a pointer. Materialize only that file:

crab hydrate models/checkpoint.bin
test "$(git hash-object models/checkpoint.bin)" = "$(cat ../checkpoint.git-hash)" \
  && echo "hash matches"

The final line should print hash matches. That is the end-to-end proof: the reader reconstructed the same bytes without the writer's staging directory.

For stronger evidence, repeat the clone in a clean container, runner, or another machine. A second directory on the writer's machine may still share credentials or an optional cache.

When a check fails

A failed upload may leave complete immutable objects that a retry can reuse. It must not advance the ref to a state with missing reachable data.

Keep five pieces of evidence

Once all five pass, the repository has crossed the complete write-and-read path. Continue with How does Crab connect to Git? to see which Git protocols produced each result.