[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

Hi again,

Andreas Metzler wrote:

> ametzler@merulo:/tmp/GIT/git-core-1.6.6-debug/t/trash directory.t1001-read-tree-m-2way$ <M.out /tmp/GIT/git-core-1.6.6-debug/git-is-binary M.out 4.out
> static buffer is not binary
> stdin is not binary
> M.out is binary
> 4.out is not binary
> > I’ve also attached a diff-debug.patch to ask git diff to reveal
> > which file it considers binary.
> ametzler@merulo:/tmp/GIT/git-core-1.6.6-debug/t/trash directory.t1001-read-tree-m-2way$ /tmp/GIT/git-core-1.6.6-debug/git-diff --no-index M.out 4.out
> a/M.out is binary
> b/4.out is binary
> diff --git a/M.out b/4.out
> index 4aefa95..d5ec90a 100644
> Binary files a/M.out and b/4.out differ

Strange: 4.out is binary for git-diff but not for git-is-binary.
Nothing obvious makes M.out significantly different from 4.out.  With
git-is-binary, 4.out, and M.out as before, could you try these?

	<4.out git-is-binary 4.out M.out
	cp M.out M2.out
	<4.out git-is-binary M.out M2.out
	<M2.out git-is-binary M.out M2.out

> FWIW all versions of git-diff I tried (1.6.6, 1.6.5, and
> report "Binary files a/M.out and b/4.out differ".

I am hoping we have enough information for a libc bug report (probably
a kernel bug, but libc is a place to start).  I have attached
generic-is-binary.c to pin this down; could you try:

	uname -r
	dpkg -l libc6
	gcc -Wall -W -O -o generic-is-binary generic-is-binary.c
	<M.out ./generic-is-binary M.out

If M.out (but not stdin) is reported to be binary, great: git is
exonerated, and we have an independent test case.

If that doesn’t work, it would be nice to learn where the unexpected
zero bytes are.  The attached xdiff-debug.patch asks
"git diff --no-index M.out 4.out" which bytes it thinks are null.

Thanks again,

Reply to: