2010-10-22 06:51:00 +00:00
|
|
|
#!/bin/sh
|
|
|
|
|
|
|
|
|
|
test_description='basic update-index tests
|
|
|
|
|
|
|
|
|
|
Tests for command-line parsing and basic operation.
|
|
|
|
|
'
|
|
|
|
|
|
csum-file: introduce discard_hashfile()
The hashfile API is used to write out a "hashfile", which has a
final checksum (typically SHA-1) at the end. An in-core hashfile
structure has up to two file descriptors and a few buffers that can
only be freed by calling a helper function that is private to the
csum-file implementation.
The usual flow of a user of the API is to first open a file
descriptor for writing, obtain a hashfile associated with that write
file descriptor by calling either hashfd() or hashfd_check(), call
hashwrite() number of times to write data to the file, and then call
finalize_hashfile(), which appends th checksum to the end of the
file, closes file descriptors and releases associated buffers.
But what if a caller finds some error after calling hashfd() to
start the process and/or hashwrite() to send some data to the file,
and wants to abort the operation? The underlying file descriptor is
often managed by the tempfile API, so aborting will clean the file
out of the filesystem, but the resources associated with the in-core
hashfile structure is lost.
Introduce discard_hashfile() API function to allow them to release
the resources held by a hashfile structure the callers want to
dispose of, and use that in read-cache.c:do_write_index(), which is
a central place that writes the index file.
Mark t2107 as leak-free, as this leak in "update-index --cacheinfo"
test that deliberately makes it fail is now plugged.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-07-25 23:07:28 +00:00
|
|
|
TEST_PASSES_SANITIZE_LEAK=true
|
2010-10-22 06:51:00 +00:00
|
|
|
. ./test-lib.sh
|
|
|
|
|
|
|
|
|
|
test_expect_success 'update-index --nonsense fails' '
|
|
|
|
|
test_must_fail git update-index --nonsense 2>msg &&
|
|
|
|
|
test -s msg
|
|
|
|
|
'
|
|
|
|
|
|
2010-12-19 03:53:58 +00:00
|
|
|
test_expect_success 'update-index --nonsense dumps usage' '
|
2010-10-22 06:51:00 +00:00
|
|
|
test_expect_code 129 git update-index --nonsense 2>err &&
|
2023-10-31 05:23:30 +00:00
|
|
|
test_grep "[Uu]sage: git update-index" err
|
2010-10-22 06:51:00 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
) &&
|
2023-10-31 05:23:30 +00:00
|
|
|
test_grep "[Uu]sage: git update-index" broken/usage
|
2010-10-22 06:51:00 +00:00
|
|
|
'
|
|
|
|
|
|
2014-06-04 07:11:11 +00:00
|
|
|
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 15:05:24 +00:00
|
|
|
test_expect_success '--cacheinfo does not accept blob null sha1' '
|
|
|
|
|
echo content >file &&
|
|
|
|
|
git add file &&
|
|
|
|
|
git rev-parse :file >expect &&
|
2022-06-16 13:13:47 +00:00
|
|
|
test_must_fail git update-index --verbose --cacheinfo 100644 $ZERO_OID file >out &&
|
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 15:05:24 +00:00
|
|
|
git rev-parse :file >actual &&
|
2022-06-16 13:13:47 +00:00
|
|
|
test_cmp expect actual &&
|
|
|
|
|
|
|
|
|
|
cat >expect <<-\EOF &&
|
|
|
|
|
add '\''file'\''
|
|
|
|
|
EOF
|
|
|
|
|
test_cmp expect out
|
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 15:05:24 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
|
|
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 &&
|
2018-05-13 02:24:13 +00:00
|
|
|
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 15:05:24 +00:00
|
|
|
git rev-parse :submodule >actual &&
|
|
|
|
|
test_cmp expect actual
|
|
|
|
|
'
|
|
|
|
|
|
2014-03-23 23:57:28 +00:00
|
|
|
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 &&
|
|
|
|
|
|
2022-06-16 13:13:47 +00:00
|
|
|
git update-index --add --verbose --cacheinfo "100644,$(cat expect),elif" >out &&
|
2014-03-23 23:57:28 +00:00
|
|
|
git rev-parse :elif >actual &&
|
2022-06-16 13:13:47 +00:00
|
|
|
test_cmp expect actual &&
|
|
|
|
|
|
|
|
|
|
cat >expect <<-\EOF &&
|
|
|
|
|
add '\''elif'\''
|
|
|
|
|
EOF
|
|
|
|
|
test_cmp expect out
|
2014-03-23 23:57:28 +00:00
|
|
|
'
|
|
|
|
|
|
2014-11-02 06:24:37 +00:00
|
|
|
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,
|
2023-03-31 14:36:04 +00:00
|
|
|
# the_index.cache_changed is zero, rollback_lock_file fails
|
2022-06-16 13:13:47 +00:00
|
|
|
git update-index --refresh --verbose >out &&
|
|
|
|
|
test_must_be_empty out &&
|
2014-11-02 06:24:37 +00:00
|
|
|
! test -f .git/index.lock
|
|
|
|
|
)
|
|
|
|
|
'
|
|
|
|
|
|
2016-09-14 21:07:45 +00:00
|
|
|
test_expect_success '--chmod=+x and chmod=-x in the same argument list' '
|
|
|
|
|
>A &&
|
|
|
|
|
>B &&
|
|
|
|
|
git add A B &&
|
2022-06-16 13:13:47 +00:00
|
|
|
git update-index --verbose --chmod=+x A --chmod=-x B >out &&
|
|
|
|
|
cat >expect <<-\EOF &&
|
|
|
|
|
add '\''A'\''
|
|
|
|
|
chmod +x '\''A'\''
|
|
|
|
|
add '\''B'\''
|
|
|
|
|
chmod -x '\''B'\''
|
|
|
|
|
EOF
|
|
|
|
|
test_cmp expect out &&
|
|
|
|
|
|
2018-03-25 19:20:55 +00:00
|
|
|
cat >expect <<-EOF &&
|
|
|
|
|
100755 $EMPTY_BLOB 0 A
|
|
|
|
|
100644 $EMPTY_BLOB 0 B
|
2016-09-14 21:07:45 +00:00
|
|
|
EOF
|
|
|
|
|
git ls-files --stage A B >actual &&
|
|
|
|
|
test_cmp expect actual
|
|
|
|
|
'
|
|
|
|
|
|
2023-09-12 19:32:34 +00:00
|
|
|
test_expect_success '--index-version' '
|
|
|
|
|
git commit --allow-empty -m snap &&
|
|
|
|
|
git reset --hard &&
|
|
|
|
|
git rm -f -r --cached . &&
|
|
|
|
|
|
|
|
|
|
# The default index version is 2 --- update this test
|
|
|
|
|
# when you change it in the code
|
|
|
|
|
git update-index --show-index-version >actual &&
|
|
|
|
|
echo 2 >expect &&
|
|
|
|
|
test_cmp expect actual &&
|
|
|
|
|
|
|
|
|
|
# The next test wants us to be using version 2
|
|
|
|
|
git update-index --index-version 2 &&
|
|
|
|
|
|
|
|
|
|
git update-index --index-version 4 --verbose >actual &&
|
|
|
|
|
echo "index-version: was 2, set to 4" >expect &&
|
|
|
|
|
test_cmp expect actual &&
|
|
|
|
|
|
|
|
|
|
git update-index --index-version 4 --verbose >actual &&
|
|
|
|
|
echo "index-version: was 4, set to 4" >expect &&
|
|
|
|
|
test_cmp expect actual &&
|
|
|
|
|
|
|
|
|
|
git update-index --index-version 2 --verbose >actual &&
|
|
|
|
|
echo "index-version: was 4, set to 2" >expect &&
|
|
|
|
|
test_cmp expect actual &&
|
|
|
|
|
|
|
|
|
|
# non-verbose should be silent
|
|
|
|
|
git update-index --index-version 4 >actual &&
|
|
|
|
|
test_must_be_empty actual
|
|
|
|
|
'
|
|
|
|
|
|
2010-10-22 06:51:00 +00:00
|
|
|
test_done
|