t7400.24 git submodule 'update --init' test fails on some machines

Some machines I don’t have access to have been hitting a test failure when building git 1.6.6.2 and 1.7.0-rc2. I am looking for ideas.

The failed test is #24 from t7400-submodule-basic.sh:

 test_expect_success 'update --init' '

	mv init init2 &&
	git config -f .gitmodules submodule.example.url "$(pwd)/init2" &&
	git config --remove-section submodule.example
	git submodule update init > update.out &&
	grep "not initialized" update.out &&
	test ! -d init/.git &&
	git submodule update --init init &&
	test -d init/.git

 '

That is supposed to produce output like

| Submodule path 'init' not initialized
| Submodule 'example' (<top>/t/trash directory.t7400-submodule-basic/init2) registered for path 'init'
| Initialized empty Git repository in <top>/t/trash directory.t7400-submodule-basic/init/.git/
| Submodule path 'init': checked out 'OBJID'
| *   ok 24: update --init

but instead it just produces

| * FAIL 24: update --init

The silence suggests that the ‘git submodule update init’ command does not perceive the submodule not to be initialized, or in other words, that one of the earlier ‘git config’ commands is failing.

None of the earlier tests fail, and none of the other t7400 tests fail.

Recent results for the ‘update --init’ test (note that even for the same arch, different builds are usually on different machines):

result git arch libc log ok 1.6.6.1 i386 2.10.2-5 [1] ok 1.6.6.1 s390 2.10.2-5 [2] ok 1.6.6.1 ia64 2.10.2-5 [3] ok 1.6.6.1 hppa 2.10.2-5 [4] ok 1.6.6.2 i386 2.10.2-5 [5] ok 1.6.6.2 s390 2.10.2-6 [6] FAIL 1.6.6.2 ia64 2.10.2-6 [7] FAIL 1.6.6.2 hppa 2.10.2-5 [8] ok 1.7.0-rc2 i386 2.10.2-6 [9] FAIL 1.7.0-rc2 s390 2.10.2-6 [10]

The two s390’s are particularly strange. Same kernel image, same libc, different machines, different results.

Unfortunately, the logs with “ok” (except for ia64 1.6.6.1) do not include “make test GIT_TEST_OPTS=-v” output.

Johan, from staring at the code, I don’t think commit 65807ee (builtin-config: Fix crash when using "-f <relative path>" from non-root dir, 2010-01-26) would have anything to do with this, but nothing else related has changed recently so I CCed you anyway.

It is hard to blame git for something so architecture-dependent and inconsistent, but one has to start somewhere.

Thoughts? Jonathan

[1] https://buildd.debian.org/fetch.cgi?&pkg=git-core&ver=1:1.6.6.1-1&arch=i386&stamp=1264681049&file=log [2] https://buildd.debian.org/fetch.cgi?&pkg=git-core&ver=1:1.6.6.1-1&arch=s390&stamp=1264681505&file=log [3] https://buildd.debian.org/fetch.cgi?&pkg=git-core&ver=1:1.6.6.1-1&arch=ia64&stamp=1264690704&file=log [4] https://buildd.debian.org/fetch.cgi?&pkg=git-core&ver=1:1.6.6.1-1&arch=hppa&stamp=1264695557&file=log [5] https://buildd.debian.org/fetch.cgi?&pkg=git-core&ver=1:1.6.6.2-1&arch=i386&stamp=1265992804&file=log [6] https://buildd.debian.org/fetch.cgi?&pkg=git-core&ver=1:1.6.6.2-1&arch=s390&stamp=1265994666&file=log [7] https://buildd.debian.org/fetch.cgi?&pkg=git-core&ver=1:1.6.6.2-1&arch=ia64&stamp=1265994466&file=log [8] https://buildd.debian.org/fetch.cgi?&pkg=git-core&ver=1:1.6.6.2-1&arch=hppa&stamp=1266038878&file=log [9] https://buildd.debian.org/fetch.cgi?&pkg=git-core&ver=1:1.7.0~rc2-1&arch=i386&stamp=1265996497&file=log [10] https://buildd.debian.org/fetch.cgi?&pkg=git-core&ver=1:1.7.0~rc2-1&arch=s390&stamp=1266025527&file=log

Recent point release builds: https://buildd.debian.org/status/package.php?p=git-core

All builds: https://buildd.debian.org/build.php?arch=&pkg=git-core