Git no longer reads attributes from the index properly

As of 34110cd4e394e3f92c01a4709689b384c34645d8, (2008-03-06, just over a year ago), Git no longer reads attributes from the index properly in all cases. This breaks initial checkouts where .gitattribute information is required to get a good checkout. [I'm also copying the msysgit guys on this, since they are probably the primary customers of autocrlf and the crlf attributes, though the problem exists in core Git.]

This support for reading attributes from the index in addition to the working directory was added in 1a9d7e9b484e77436edc7f5cacd39c24ec605e6d, on 2007-08-14:

commit 1a9d7e9b484e77436edc7f5cacd39c24ec605e6d
Author: Junio C Hamano <gitster@pobox.com>
Date:   Tue Aug 14 01:41:02 2007 -0700

    attr.c: read .gitattributes from index as well.

    This makes .gitattributes files to be read from the index when
    they are not checked out to the work tree.  This is in line with
    the way we always allowed low-level tools to operate in sparsely
    checked out work tree in a reasonable way.

    It swaps the order of new file creation and converting the blob
    to work tree representation; otherwise when we are in the middle
    of checking out .gitattributes we would notice an empty but
    unwritten .gitattributes file in the work tree and will ignore
    the copy in the index.

    Signed-off-by: Junio C Hamano <gitster@pobox.com>

This worked until the following commit:

34110cd4e394e3f92c01a4709689b384c34645d8 is first bad commit
commit 34110cd4e394e3f92c01a4709689b384c34645d8
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Thu Mar 6 18:12:28 2008 -0800

    Make 'unpack_trees()' have a separate source and destination index

    We will always unpack into our own internal index, but we will take the
    source from wherever specified, and we will optionally write the result
    to a specified index (optionally, because not everybody even _wants_ any
    result: the index diffing really wants to just walk the tree and index
    in parallel).

    This ends up removing a fair number more lines than it adds, for the
    simple reason that we can now skip all the crud that tried to be
    oh-so-careful about maintaining our position in the index as we were
    traversing and modifying it.  Since we don't actually modify the source
    index any more, we can just update the 'o->pos' pointer without worrying
    about whether an index entry got removed or replaced or added to.

    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>

Unfortunately I don't have the foggiest on how to fix this. However, I did write a new test case to catch this bug, as the existing ones were insufficiently destructive to trigger it. This test case is ugly, uses porcelain, and is probably overly-destructive, but it does show the problem. It fails on 34110cd4 and succeeds on 34110cd4^.

I don't expect the test case can be accepted as-is, but regardless:

Signed-off-by: Brian Downing <bdowning@lavos.net>
---
 t/t0020-crlf.sh |   19 +++++++++++++++++++
 1 files changed, 19 insertions(+), 0 deletions(-)