On Thu, Sep 22, 2011 at 6:39 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > 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. I agree with that... > 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. ... but it still seems inconsistent that --cached ignores the working tree except for .gitattributes. This also happens to be the only way to get diff-index to work with a bare repo and temporary (on-disk) index. But that's less important if we implement what's suggested in the next paragraph. > 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. Okay, I can give that a try. > 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. --[no-]tree-attributes? j. -- 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