On 3/14/2022 11:05 AM, Derrick Stolee wrote:
> On 3/11/2022 7:08 PM, Victoria Dye via GitGitGadget wrote:
>> From: Victoria Dye <vdye@xxxxxxxxxx>
>> +test_index_refreshed () {
>> +
>> + # To test whether the index is refresh, create a scenario where a
>> + # command will fail if the index is *not* refreshed:
>> + # 1. update the worktree to match HEAD & remove file2 in the index
>> + # 2. reset --mixed to unstage the change from step 1
>> + # 3. read-tree HEAD~1 (which differs from HEAD in file2)
>> + # If the index is refreshed in step 2, then file2 in the index will be
>> + # up-to-date with HEAD and read-tree will succeed (thus failing the
>> + # test). If the index is *not* refreshed, however, the staged deletion
>> + # of file2 from step 1 will conflict with the changes from the tree read
>> + # in step 3, resulting in a failure.
>> +
>> + # Step 0: start with a clean index
>> + git reset --hard HEAD &&
>> +
>> + # Step 1
>> + git rm --cached file2 &&
>> +
>> + # Step 2
>> + git reset $1 --mixed HEAD &&
> Perhaps you want to have two arguments: one for config settings
> and another for arguments, meaning your call in test_index_refreshed
> should be
>
> git $1 reset $2 --mixed HEAD
>
> and calls like this should be
>
> test_index_refreshed "-c reset.quiet=true" "" &&
After looking at your other examples, I thought of another example
that you might want to consider.
In the helper, use:
git $@ --mixed HEAD &&
and then for the callers, use
test_index_refreshed refresh &&
or
test_index_refreshed -c reset.quiet=true refresh &&
or
test_index_refreshed refresh --quiet &&
and similarly through the other tests.
Thanks,
-Stolee
