git-commit-vandalism/t/t2107-update-index-basic.sh

96 lines
2.4 KiB
Bash
Raw Normal View History

#!/bin/sh
test_description='basic update-index tests
Tests for command-line parsing and basic operation.
'
. ./test-lib.sh
test_expect_success 'update-index --nonsense fails' '
test_must_fail git update-index --nonsense 2>msg &&
test -s msg
'
test_expect_success 'update-index --nonsense dumps usage' '
test_expect_code 129 git update-index --nonsense 2>err &&
test_i18ngrep "[Uu]sage: git update-index" err
'
test_expect_success 'update-index -h with corrupt index' '
mkdir broken &&
(
cd broken &&
git init &&
>.git/index &&
test_expect_code 129 git update-index -h >usage 2>&1
) &&
test_i18ngrep "[Uu]sage: git update-index" broken/usage
'
test_expect_success '--cacheinfo complains of missing arguments' '
test_must_fail git update-index --cacheinfo
'
do not write null sha1s to on-disk index We should never need to write the null sha1 into an index entry (short of the 1 in 2^160 chance that somebody actually has content that hashes to it). If we attempt to do so, it is much more likely that it is a bug, since we use the null sha1 as a sentinel value to mean "not valid". The presence of null sha1s in the index (which can come from, among other things, "update-index --cacheinfo", or by reading a corrupted tree) can cause problems for later readers, because they cannot distinguish the literal null sha1 from its use a sentinel value. For example, "git diff-files" on such an entry would make it appear as if it is stat-dirty, and until recently, the diff code assumed such an entry meant that we should be diffing a working tree file rather than a blob. Ideally, we would stop such entries from entering even our in-core index. However, we do sometimes legitimately add entries with null sha1s in order to represent these sentinel situations; simply forbidding them in add_index_entry breaks a lot of the existing code. However, we can at least make sure that our in-core sentinel representation never makes it to disk. To be thorough, we will test an attempt to add both a blob and a submodule entry. In the former case, we might run into problems anyway because we will be missing the blob object. But in the latter case, we do not enforce connectivity across gitlink entries, making this our only point of enforcement. The current implementation does not care which type of entry we are seeing, but testing both cases helps future-proof the test suite in case that changes. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-28 17:05:24 +02:00
test_expect_success '--cacheinfo does not accept blob null sha1' '
echo content >file &&
git add file &&
git rev-parse :file >expect &&
test_must_fail git update-index --cacheinfo 100644 $ZERO_OID file &&
do not write null sha1s to on-disk index We should never need to write the null sha1 into an index entry (short of the 1 in 2^160 chance that somebody actually has content that hashes to it). If we attempt to do so, it is much more likely that it is a bug, since we use the null sha1 as a sentinel value to mean "not valid". The presence of null sha1s in the index (which can come from, among other things, "update-index --cacheinfo", or by reading a corrupted tree) can cause problems for later readers, because they cannot distinguish the literal null sha1 from its use a sentinel value. For example, "git diff-files" on such an entry would make it appear as if it is stat-dirty, and until recently, the diff code assumed such an entry meant that we should be diffing a working tree file rather than a blob. Ideally, we would stop such entries from entering even our in-core index. However, we do sometimes legitimately add entries with null sha1s in order to represent these sentinel situations; simply forbidding them in add_index_entry breaks a lot of the existing code. However, we can at least make sure that our in-core sentinel representation never makes it to disk. To be thorough, we will test an attempt to add both a blob and a submodule entry. In the former case, we might run into problems anyway because we will be missing the blob object. But in the latter case, we do not enforce connectivity across gitlink entries, making this our only point of enforcement. The current implementation does not care which type of entry we are seeing, but testing both cases helps future-proof the test suite in case that changes. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-28 17:05:24 +02:00
git rev-parse :file >actual &&
test_cmp expect actual
'
test_expect_success '--cacheinfo does not accept gitlink null sha1' '
git init submodule &&
(cd submodule && test_commit foo) &&
git add submodule &&
git rev-parse :submodule >expect &&
test_must_fail git update-index --cacheinfo 160000 $ZERO_OID submodule &&
do not write null sha1s to on-disk index We should never need to write the null sha1 into an index entry (short of the 1 in 2^160 chance that somebody actually has content that hashes to it). If we attempt to do so, it is much more likely that it is a bug, since we use the null sha1 as a sentinel value to mean "not valid". The presence of null sha1s in the index (which can come from, among other things, "update-index --cacheinfo", or by reading a corrupted tree) can cause problems for later readers, because they cannot distinguish the literal null sha1 from its use a sentinel value. For example, "git diff-files" on such an entry would make it appear as if it is stat-dirty, and until recently, the diff code assumed such an entry meant that we should be diffing a working tree file rather than a blob. Ideally, we would stop such entries from entering even our in-core index. However, we do sometimes legitimately add entries with null sha1s in order to represent these sentinel situations; simply forbidding them in add_index_entry breaks a lot of the existing code. However, we can at least make sure that our in-core sentinel representation never makes it to disk. To be thorough, we will test an attempt to add both a blob and a submodule entry. In the former case, we might run into problems anyway because we will be missing the blob object. But in the latter case, we do not enforce connectivity across gitlink entries, making this our only point of enforcement. The current implementation does not care which type of entry we are seeing, but testing both cases helps future-proof the test suite in case that changes. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-28 17:05:24 +02:00
git rev-parse :submodule >actual &&
test_cmp expect actual
'
test_expect_success '--cacheinfo mode,sha1,path (new syntax)' '
echo content >file &&
git hash-object -w --stdin <file >expect &&
git update-index --add --cacheinfo 100644 "$(cat expect)" file &&
git rev-parse :file >actual &&
test_cmp expect actual &&
git update-index --add --cacheinfo "100644,$(cat expect),elif" &&
git rev-parse :elif >actual &&
test_cmp expect actual
'
test_expect_success '.lock files cleaned up' '
mkdir cleanup &&
(
cd cleanup &&
mkdir worktree &&
git init repo &&
cd repo &&
git config core.worktree ../../worktree &&
# --refresh triggers late setup_work_tree,
# active_cache_changed is zero, rollback_lock_file fails
git update-index --refresh &&
! test -f .git/index.lock
)
'
test_expect_success '--chmod=+x and chmod=-x in the same argument list' '
>A &&
>B &&
git add A B &&
git update-index --chmod=+x A --chmod=-x B &&
cat >expect <<-EOF &&
100755 $EMPTY_BLOB 0 A
100644 $EMPTY_BLOB 0 B
EOF
git ls-files --stage A B >actual &&
test_cmp expect actual
'
test_done