Re: [PATCH v3 1/1] fsmonitor: don't fill bitmap with entries to be removed

[Junio C Hamano <gitster@pobox.com>]

"William Baker via GitGitGadget" <gitgitgadget@gmail.com> writes:

> +# Test staging/unstaging files that appear at the end of the index.  Test
> +# file names begin with 'z' so that they are sorted to the end of the index. 

Well, the test is now done in a freshly created repository, so the
z* files are the only thing you have in here---technically they are
at the end of the index, but so they are at the beginning, too.

Would it affect the effectiveness of the test that you do not have
any other paths in the working tree or in the index, unlike the test
in the previous rounds that did not use a newly created test
repository?  

This is not a rhetorical question, but purely asking. "no, this
still tests what we want to test and shows breakage when the fix to
the code in the patch gets reverted" is perfectly a good answer, but
in that case, is "the end of" the most important trait of the
condition this test is checking?  Wouldn't the bug be exposed as
long as we remove sufficiently large number of entries (like
"removing more paths than the paths still in the index at the end"
or something like that)?

Thanks.

> +test_expect_success 'status succeeds after staging/unstaging ' '
> +	test_create_repo fsmonitor-stage-unstage &&
> +	(
> +		cd fsmonitor-stage-unstage &&
> +		test_commit initial &&
> +		git update-index --fsmonitor &&
> +		removed=$(test_seq 1 100 | sed "s/^/z/") &&
> +		touch $removed &&
> +		git add $removed &&
> +		git config core.fsmonitor "$TEST_DIRECTORY/t7519/fsmonitor-env" &&
> +		FSMONITOR_LIST="$removed" git restore -S $removed &&
> +		FSMONITOR_LIST="$removed" git status
> +	)
> +'
> +
>  test_done
> diff --git a/t/t7519/fsmonitor-env b/t/t7519/fsmonitor-env
> new file mode 100755
> index 0000000000..8f1f7ab164
> --- /dev/null
> +++ b/t/t7519/fsmonitor-env
> @@ -0,0 +1,24 @@
> +#!/bin/sh
> +#
> +# An test hook script to integrate with git to test fsmonitor.
> +#
> +# The hook is passed a version (currently 1) and a time in nanoseconds
> +# formatted as a string and outputs to stdout all files that have been
> +# modified since the given time. Paths must be relative to the root of
> +# the working tree and separated by a single NUL.
> +#
> +#echo "$0 $*" >&2
> +
> +if test "$#" -ne 2
> +then
> +	echo "$0: exactly 2 arguments expected" >&2
> +	exit 2
> +fi
> +
> +if test "$1" != 1
> +then
> +	echo "Unsupported core.fsmonitor hook version." >&2
> +	exit 1
> +fi
> +
> +printf '%s\n' $FSMONITOR_LIST