2009-08-11 17:43:59 +02:00
|
|
|
#!/bin/sh
|
|
|
|
|
|
|
|
test_description='diff with assume-unchanged entries'
|
|
|
|
|
2022-04-13 22:01:53 +02:00
|
|
|
TEST_PASSES_SANITIZE_LEAK=true
|
2009-08-11 17:43:59 +02:00
|
|
|
. ./test-lib.sh
|
|
|
|
|
|
|
|
# external diff has been tested in t4020-diff-external.sh
|
|
|
|
|
|
|
|
test_expect_success 'setup' '
|
|
|
|
echo zero > zero &&
|
|
|
|
git add zero &&
|
|
|
|
git commit -m zero &&
|
|
|
|
echo one > one &&
|
|
|
|
echo two > two &&
|
2019-10-28 01:59:04 +01:00
|
|
|
blob=$(git hash-object one) &&
|
2009-08-11 17:43:59 +02:00
|
|
|
git add one two &&
|
|
|
|
git commit -m onetwo &&
|
|
|
|
git update-index --assume-unchanged one &&
|
|
|
|
echo borked >> one &&
|
|
|
|
test "$(git ls-files -v one)" = "h one"
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'diff-index does not examine assume-unchanged entries' '
|
2019-10-28 01:59:04 +01:00
|
|
|
git diff-index HEAD^ -- one | grep -q $blob
|
2009-08-11 17:43:59 +02:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'diff-files does not examine assume-unchanged entries' '
|
|
|
|
rm one &&
|
|
|
|
test -z "$(git diff-files -- one)"
|
|
|
|
'
|
|
|
|
|
run_diff_files: do not look at uninitialized stat data
If we try to diff an index entry marked CE_VALID (because it
was marked with --assume-unchanged), we do not bother even
running stat() on the file to see if it was removed. This
started long ago with 540e694 (Prevent diff machinery from
examining assume-unchanged entries on worktree, 2009-08-11).
However, the subsequent code may look at our "struct stat"
and expect to find actual data; currently it will find
whatever cruft was left on the stack. This can cause
problems in two situations:
1. We call match_stat_with_submodule with the stat data,
so a submodule may be erroneously marked as changed.
2. If --find-copies-harder is in effect, we pass all
entries, even unchanged ones, to diff_change, so it can
list them as rename/copy sources. Since we found no
change, we assume that function will realize it and not
actually display any diff output. However, we end up
feeding it a bogus mode, leading it to sometimes claim
there was a mode change.
We can fix both by splitting the CE_VALID and regular code
paths, and making sure only to look at the stat information
in the latter. Furthermore, we push the declaration of our
"struct stat" down into the code paths that actually set it,
so we cannot accidentally access it uninitialized in future
code.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-15 00:13:06 +02:00
|
|
|
test_expect_success POSIXPERM 'find-copies-harder is not confused by mode bits' '
|
|
|
|
echo content >exec &&
|
|
|
|
chmod +x exec &&
|
|
|
|
git add exec &&
|
|
|
|
git commit -m exec &&
|
|
|
|
git update-index --assume-unchanged exec &&
|
|
|
|
git diff-files --find-copies-harder -- exec >actual &&
|
2018-07-27 19:48:11 +02:00
|
|
|
test_must_be_empty actual
|
run_diff_files: do not look at uninitialized stat data
If we try to diff an index entry marked CE_VALID (because it
was marked with --assume-unchanged), we do not bother even
running stat() on the file to see if it was removed. This
started long ago with 540e694 (Prevent diff machinery from
examining assume-unchanged entries on worktree, 2009-08-11).
However, the subsequent code may look at our "struct stat"
and expect to find actual data; currently it will find
whatever cruft was left on the stack. This can cause
problems in two situations:
1. We call match_stat_with_submodule with the stat data,
so a submodule may be erroneously marked as changed.
2. If --find-copies-harder is in effect, we pass all
entries, even unchanged ones, to diff_change, so it can
list them as rename/copy sources. Since we found no
change, we assume that function will realize it and not
actually display any diff output. However, we end up
feeding it a bogus mode, leading it to sometimes claim
there was a mode change.
We can fix both by splitting the CE_VALID and regular code
paths, and making sure only to look at the stat information
in the latter. Furthermore, we push the declaration of our
"struct stat" down into the code paths that actually set it,
so we cannot accidentally access it uninitialized in future
code.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-15 00:13:06 +02:00
|
|
|
'
|
|
|
|
|
2009-08-11 17:43:59 +02:00
|
|
|
test_done
|