I usually try to make sure all four integration branches (maint, master,
next and pu) pass the selftest before pushing the results out, but it
seems that there is a subtle breakage somewhere in 'pu' that breaks
t4203-mailmap.sh. The breakage is not reliably reproducible but happens
very often when tests are run in parallel (e.g. "make -j4").
I originally was planning to merge ms/mailmap to 'next' before tonight's
pushout, but I ran out of time and had to yank the topic out of 'next' and
kicked it back to 'pu'.
Does the following log ring a bell to anybody?
----------------------------------------------------------------
Initialized empty Git repository in /git/git.git/t/trash directory.t4203-mailmap/.git/
* expecting success:
echo one >one &&
git add one &&
test_tick &&
git commit -m initial &&
echo two >>one &&
git add one &&
git commit --author "nick1 <bugs@xxxxxxxxxx>" -m second
[master (root-commit) 3a2fdcb] initial
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 one
[master 7de6f99] second
1 files changed, 1 insertions(+), 0 deletions(-)
* ok 1: setup
* expecting success:
git shortlog >actual &&
test_cmp expect actual
--- expect 2009-02-06 10:47:25.000000000 +0000
+++ actual 2009-02-06 10:47:25.000000000 +0000
@@ -1,6 +0,0 @@
-A U Thor (1):
- initial
-
-nick1 (1):
- second
-
* FAIL 2: No mailmap
git shortlog >actual &&
test_cmp expect actual
make[2]: *** [t4203-mailmap.sh] Error 1
----------------------------------------------------------------
The frustrating thing is that
GIT_SKIP_TESTS='t[0-35-9]??? t4[01]??' \
GIT_TEST_OPTS='-i -v' \
make -j4 test
fails very reliably with the above log, but:
(1) running the same "../../git-shortlog" in "t/trash directory.t4203-mailmap/"
immediately after the test failed does emit the expected result;
(2) going down to t/ and manually running t4203-mailmap.sh alone succeeds;
(3) running the tests serially (i.e. without -j4) allows the test to succeed.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
