bug in t3700-add.sh?

Hi,

Running test 17, I got this output:

* expecting success:
        git rm --cached -f file symlink &&
        (
                echo "100644 $(git hash-object -w stage1) 1     file"
                echo "100755 $(git hash-object -w stage2) 2     file"
                echo "100644 $(printf $s | git hash-object -w -t blob
--stdin) 1        symlink"
                echo "120000 $(printf $s | git hash-object -w -t blob
--stdin) 2        symlink"
        ) | git update-index --index-info &&
        git config core.filemode 0 &&
        git config core.symlinks 0 &&
        echo new > file &&
        echo new > symlink &&
        git add file symlink &&
        git ls-files --stage | grep "^100755 .* 0       file$" &&
        git ls-files --stage | grep "^120000 .* 0       symlink$"

rm 'file'
rm 'symlink'
printf: usage: printf [-v var] format [arguments]
printf: usage: printf [-v var] format [arguments]
100755 3e757656cf36eca53338e520d134963a44f793f8 0       file
120000 3e757656cf36eca53338e520d134963a44f793f8 0       symlink
*   ok 17: git add with filemode=0, symlinks=0 prefers stage 2 over stage 1

I don't know if "printf $s" was intentional because $s was empty and caused printf to print out help usage. I have feeling that there is something wrong here. Anyone can clarify?

Johannes Sixt CC'd as he added this code.

"Nguyen Thai Ngoc Duy" <pclouds@gmail.com> writes:

Gaah.  Those $s seem completely bogus.

"Nguyen Thai Ngoc Duy" <pclouds@gmail.com> writes:

Gaah.  Those $s seem completely bogus.

This test only cares to see if the blob type is retained (it does "git add" to the path later to throw away the unmergedness and data at higher stage prepared by this step), so it really does not matter what is fed to hash-object. But it should be hashing a file whose contents is '1' and a symlink to '2'.