Jay Soffian <jaysoffian@xxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html