Junio C Hamano <gitster@xxxxxxxxx> writes: >> +test_expect_success 'error out on missing blob objects' ' >> + echo 1 | git hash-object -w --stdin >blob1 && >> + echo 2 | git hash-object -w --stdin >blob2 && >> + echo 3 | git hash-object -w --stdin >blob3 && >> + printf "100644 blob $(cat blob1)\tblob\n" | git mktree >tree1 && >> + printf "100644 blob $(cat blob2)\tblob\n" | git mktree >tree2 && >> + printf "100644 blob $(cat blob3)\tblob\n" | git mktree >tree3 && >> + git init --bare missing-blob.git && >> + cat blob1 blob3 tree1 tree2 tree3 | >> + git pack-objects missing-blob.git/objects/pack/side1-whatever-is-missing && >> + test_must_fail git --git-dir=missing-blob.git >actual 2>err \ >> + merge-tree --merge-base=$(cat tree1) $(cat tree2) $(cat tree3) && >> + test_grep "unable to read blob object $(cat blob2)" err && >> + test_must_be_empty actual >> +' > > It would have been even easier to see that blob2 is what we expect > to be complained about, if you listed all objects and filtered blob2 > out, but the number of objects involved here is so small, a "cat" of > all objects we want to keep is OK here. Just FYI for anybody reading from the sideline. git cat-file --unordered \ --batch-check="%(objectname)" --batch-all-objects | grep -v $(cat blob2) | git pack-objects ... would be a compact way to say "Give me a pack that lets me easily simulate what happens in a repository identical to the current one, if it lacked object "blob2", without having to enumerate what object we want to include in the test repository. Again, I think in this particular case, it is easy enough to see in the "blob1 blob3 tree1 tree2 tree3" enumeration what is missing, so the way the patch is written is fine. Thanks.
