Johannes Sixt <j...@kdbg.org> writes:
> Good to know that I am not alone. This one fails consistently for
> me. I dug into it a bit today, but it drives me mad. Process Monitor
> reports that the redirected-to file (git-stderr.log) gets marked as
> "Delete pending" by git.exe, but I have absolutely no clue where this
> is coming from. Git.exe has no business fuzzing with the file; it just
> has to write() something into it, if at all. When 'git checkout' ends,
> the file is closed, and removed due to the "Delete pending" mark. At
> the same time, git.exe finishes with non-zero exit code. For whatever
> reason.
>
>> FWIW: This patch (which would be the right thing to do anyways) seems to fix
>> the flakyness but I can't be sure ... it needs to run longer...
>>
>> diff --git a/t/t0021-conversion.sh b/t/t0021-conversion.sh
>> index 9ff5027..107766b 100755
>> --- a/t/t0021-conversion.sh
>> +++ b/t/t0021-conversion.sh
>> @@ -29,8 +29,7 @@ file_size () {
>>
>> filter_git () {
>> rm -f rot13-filter.log &&
>> - git "$@" 2>git-stderr.log &&
>> - rm -f git-stderr.log
>> + git "$@" 2>/dev/null
>
> If I remove the redirection altogether, the test passes for me
> consistently. The redirection isn't necessary anyway, it looks like a
> debugging left-over.
OK, then let's have
filter_git () {
rm -f rot13-filter.log &&
git "$@"
...
and call that -rc1; to Windows folks, this is sweeping a mysterious
failure around git.exe under the rug, but for the purpose of the
overall project, it is far lower priority to figure out the reason
why a merely-redirected-into file is considered to be delete-pending
on WIndows than have something the end user can start testing and
complaining about new features and regressions.
Thanks.
