summaryrefslogtreecommitdiff
path: root/t/t1060-object-corruption.sh
diff options
context:
space:
mode:
authorJeff King <peff@peff.net>2019-03-04 17:40:54 (GMT)
committerJunio C Hamano <gitster@pobox.com>2019-03-05 13:28:29 (GMT)
commitf06ab027efd2cff4c4319354f1ad7d5f09e853a1 (patch)
tree4b888d4e879a94211bd2babf1735ac411c647419 /t/t1060-object-corruption.sh
parent7c0fe330d5f3d2fc7aac57a19c7580ea2543c799 (diff)
downloadgit-f06ab027efd2cff4c4319354f1ad7d5f09e853a1.zip
git-f06ab027efd2cff4c4319354f1ad7d5f09e853a1.tar.gz
git-f06ab027efd2cff4c4319354f1ad7d5f09e853a1.tar.bz2
rev-list: allow cached objects in existence check
This fixes a regression in 7c0fe330d5 (rev-list: handle missing tree objects properly, 2018-10-05) where rev-list will now complain about the empty tree when it doesn't physically exist on disk. Before that commit, we relied on the traversal code in list-objects.c to walk through the trees. Since it uses parse_tree(), we'd do a normal object lookup that includes looking in the set of "cached" objects (which is where our magic internal empty-tree kicks in). After that commit, we instead tell list-objects.c not to die on any missing trees, and we check them ourselves using has_object_file(). But that function uses OBJECT_INFO_SKIP_CACHED, which means we won't use our internal empty tree. This normally wouldn't come up. For most operations, Git will try to write out the empty tree object as it would any other object. And pack-objects in a push or fetch will send the empty tree (even if it's virtual on the sending side). However, there are cases where this can matter. One I found in the wild: 1. The root tree of a commit became empty by deleting all files, without using an index. In this case it was done using libgit2's tree builder API, but as the included test shows, it can easily be done with regular git using hash-object. The resulting repo works OK, as we'd avoid walking over our own reachable commits for a connectivity check. 2. Cloning with --reference pointing to the repository from (1) can trigger the problem, because we tell the other side we already have that commit (and hence the empty tree), but then walk over it during the connectivity check (where we complain about it missing). Arguably the workflow in step (1) should be more careful about writing the empty tree object if we're referencing it. But this workflow did work prior to 7c0fe330d5, so let's restore it. This patch makes the minimal fix, which is to swap out a direct call to oid_object_info_extended(), minus the SKIP_CACHED flag, instead of calling has_object_file(). This is all that has_object_file() is doing under the hood. And there's little danger of unrelated fallout from other unexpected "cached" objects, since there's only one call site that ends such a cached object, and it's in git-blame. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 't/t1060-object-corruption.sh')
-rwxr-xr-xt/t1060-object-corruption.sh10
1 files changed, 10 insertions, 0 deletions
diff --git a/t/t1060-object-corruption.sh b/t/t1060-object-corruption.sh
index ac1f189..807b63b 100755
--- a/t/t1060-object-corruption.sh
+++ b/t/t1060-object-corruption.sh
@@ -125,4 +125,14 @@ test_expect_success 'fetch into corrupted repo with index-pack' '
)
'
+test_expect_success 'internal tree objects are not "missing"' '
+ git init missing-empty &&
+ (
+ cd missing-empty &&
+ empty_tree=$(git hash-object -t tree /dev/null) &&
+ commit=$(echo foo | git commit-tree $empty_tree) &&
+ git rev-list --objects $commit
+ )
+'
+
test_done