Re: [PATCH 2/2] diff_index: honor in-index, not working-tree, .gitattributes

[Junio C Hamano <gitster@pobox.com>]

Jay Soffian <jaysoffian@gmail.com> writes:

> When diff'ing the index against a tree (using either diff-index
> or diff --cached), git previously looked at .gitattributes in the
> working tree before considering .gitattributes in the index, even
> though the diff itself otherwise ignores the working tree.

We can take attributes only from one place (so far from the working tree
and perhaps from the index), people had to live within the limitation that
comes from the "single source only" semantics. It also happens to be
easier to understand (recall the complexity of the examples Jeff gave
about "textconv" during "diff" which ideally should apply from its own
side and "funcname", which does not even have a right answer).

In practice, because development progresses by making everything
(including the .gitattributes file) better, I think "use the newer one"
would be a good compromise when we have two possible sources to grab
attributes from but we can only use one source.

In that sense, I am somewhat skeptical about what this patch tries to
do. The working tree is where people make the progress to update the
index.

A related tangent.

I think the logical conclusion of assuming that we will keep the "single
source only" semantics (which I think we will, by the way, unless I hear a
concrete proposal to how we apply attributes from more than one sources in
what way to which side of the diff) is that a patch might be an
improvement over the current behaviour if it teaches "diff-tree" to read
from the tree and populate the in-core index (never writing it out to
$GIT_DIR/index) from the postimage tree (i.e. "diff preimage postimage" or
"diff -R postimage preimage") when it is run in a bare repository. It
would be a regression if the attributes mechanism is used for auditing
purposes (as we start reading from a tree that is being audited using the
very attributes it brings in), though.