Re: How to use git attributes to configure server-side checks?

[Michael Haggerty <mhagger@alum.mit.edu>]

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@alum.mit.edu
http://softwareswirl.blogspot.com/