Re: 2.11.0-rc1 will not be tagged for a few days

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 11, 2016, 20:52 UTC
Message-ID: <xmqq1syh3fjx.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <e0785e35-b43d-37ed-598d-b458daf3c355@kdbg.org>

Johannes Sixt <j6t@kdbg.org> writes:

Show 28 quoted lines

> 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.