Karthik Nayak <karthik.188@xxxxxxxxx> writes:
>> + cat file >file.new &&
>> + mv file.new file &&
>> + git describe --dirty >actual &&
>> + echo "A" >expected &&
>> + test_cmp expected actual &&
>> +
>> + cat file >file.new &&
>> + mv file.new file &&
>> + git describe --dirty --broken >actual &&
>> + echo "A" >expected &&
>> + test_cmp expected actual
>
> Not worth a reroll, but you don't have to create file.new twice.
I think you have to make the "file" stat-dirty again after the first
test, as a successful first test _should_ refresh the index (and
that was why my manual illustration in an earlier message
<xmqqsex2b4ti.fsf@gitster.g> did "--dirty --broken" first before
"--dirty" alone, knowing that the former fails to refresh the
index).
You are right to point out that the expected results for "--dirty"
and "--dirty --broken" are the same and we do not have to create it
twice, though.
If the filesystem has a usable inode number, then replacing "file"
with a copy, i.e. "cat file >file.new && mv file.new file", is an
excellent way to ensure that the stat data becomes dirty even when
it is done as a part of a quick series of commands. But not all
filesystems we run our tests on may have usable inode number, so it
may not be the best thing to do in an automated test. We could use
"test-tool chmtime" instead, perhaps like:
... make the index and the working tree are clean wrt HEAD ...
# we do not expect -dirty suffix in the output
echo A >expect &&
# make "file" stat-dirty
test-tool chmtime -10 file &&
# "describe --dirty" refreshes and does not get fooled
git describe --dirty >actual &&
test_cmp expect actual &&
# make "file" stat-dirty again
test-tool chmtime -10 file &&
# "describe --dirty --broken" refreshes and does not get fooled
git describe --dirty --broken >actual &&
test_cmp expect actual
with the extra comments stripped (I added them only to explain what
is going on to the readers of this e-mail message).
