On 09/22/2011 10:58 PM, Jeff King wrote: > However, I think this is skirting around a somewhat larger issue, which > is that gitattributes are sometimes about "this is what the file is like > at the current state of history", and sometimes about "this is what this > file is like throughout history". This is a very dangerous line of thought. When content is read out of a historical commit, the content must be identical to what was checked into that commit. For example, the EOL characters that I see in an old file revision must not depend on my current HEAD or index. This rule should apply regardless of whether the content is being read to be checked out, put into an archive, or diffed against some other revision. So for these purposes, I think there is no choice but to honor the gitattributes files in the tree/index/directory from which the content was read. If the user really wants to say "this is what this file is like throughout history" (thereby altering history), then this should be a local decision that should be stored locally in $GIT_DIR/info/attributes. There are other attributes that affect "two-argument" operations like diff. Here the policy has to depend on the situation. In the case of diff, I suggest that the relevant attributes be read from *both* versions of the file. If they are the same, then obviously use them. If they differ, then fall back to a "safe" default (for example, the diff that would be used if *no* attributes had been specified). However, as a special case, if an attribute is specified in one version and unspecified in another, it would *usually* be OK to use the specified version of the attributes and that might be considered a reasonable alternative. By the way, it is possible that the two ends of a diff operation have different filenames (e.g., with -M or -C). In this case the attributes should be looked up using the filename corresponding to the commit. > So I think doing it "right" would be a lot more complicated than just > reading the commits from a particular tree. I think it would mean adding > more context to all attribute lookups, and having each caller decide how > the results should be used. I agree. > So if the status quo with working trees (i.e., retroactively applying > the current gitattributes to past commits) is good enough, perhaps the > bare-repository solution should be modeled the same way? In other words, > should "git log -p" in a bare repo be looking for attributes not in the > commits being diffed, but rather in HEAD[2]? This would be a very poor policy, modeled on a status quo that is *not* good enough. For example, HEAD might not even be a descendant of the commit whose content is being interrogated; the commit might have new files and new gitattributes that would be ignored. I suppose your suggestion is better than the status quo, so it would be fine as a starting point, *provided* it is clear that people should not rely on this behavior not being improved later. Michael -- Michael Haggerty mhagger@xxxxxxxxxxxx http://softwareswirl.blogspot.com/ -- 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