Re: git-core FTBFS on ia64: t1001-read-tree-m-2way.sh test fails

[Jonathan Nieder <jrnieder@gmail.com>]

Hi Itanium porters,

The git test suite is failing on mundy.  Any ideas about why?
(Or about how to try to investigate this --- a good emulator?  machine
access?  a willing guinea pig who can try patches?)

Some details on the test failure follow.

Anders Kaseorg wrote:

> Some time between 1.6.5-1 and 1.6.5.2-1, git-core started failing to build 
> on ia64, because the test t1001-read-tree-m-2way.sh is failing.  This has 
> continued in every version up through 1.6.6-1.

> Full build log:
> https://buildd.debian.org/build.php?arch=ia64&pkg=git-core&ver=1%3A1.6.5.2-1

The more recent log linked to from
<https://buildd.debian.org/~luk/status/package.php?p=git-core> shows
the same problem, so that is what I will use.

The alpha log was useful for figuring out the expected output.

In test 1001, all is well until subtest 3:

| test_expect_success \
|     '4 - carry forward local addition.' \
|     'rm -f .git/index &&
|      git read-tree $treeH &&
|      git checkout-index -u -f -q -a &&
|      git update-index --add yomin &&
|      read_tree_twoway $treeH $treeM &&
|      git ls-files --stage >4.out || return 1
|      git diff M.out 4.out >4diff.out
|      compare_change 4diff.out expected &&
|      check_cache_at yomin clean'

This test checks that fast-forwarding with 'git read-tree -m'
with a file not tracked in the head or MERGE_HEAD leaves that file
untouched in the work tree and unmodified in the index.

treeH and treeM are described in test 1 (setup).  They ensure that
each possible type of fast-forward for a file occurs:

|         bozbar  - in H, stays in M, modified from bozbar to gnusto
|         frotz   - not in H added in M
|         nitfol  - in H, stays in M unmodified
|         rezrov  - in H, deleted in M
|         yomin   - not in H nor M

The test resets the index and tracked work tree files to match H, adds
yomin to the index, and then tries to fast-forward.  yomin should be
left alone.

So far so good, as the read_tree_twoway output reveals:

| 100644 346d4e61f111336a1443ef6b2e834aa5b1a7f91a 0       bozbar
| 100644 8e4020bb5a8d8c873b25de15933e75cc0fc275df 0       frotz
| 100644 dca6b92303befc93086aa025d90a5facd7eb2812 0       nitfol
| 100644 0a41e115ab61be0328a19b29f18cdcb49338d516 0       yomin

This listing is saved in 4.out.  That file is diffed against M.out
to emphasize the yomin index entry.  We expect something like

... diff header ...
+100644 0a41e115ab61be...16 0      yomin

to demonstrate that yomin is still in the index.  But instead,
4diff.out is empty!

That is, yomin has been deleted from the index for some reason,
but only on the ia64.

The same problem applies to test 4.

Thoughts?
Jonathan