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

Johannes Sixt [off-list ref] 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.

quoted

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.