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

From: Jay Soffian <jaysoffian@gmail.com>
Date: Sep 23, 2011, 15:50 UTC
Message-ID: <CAG+J_Dz7uQcYjwEZrAg-h2GAwJ0gCjW2kw2Erz3UWGYcCeTAVQ@mail.gmail.com>
In-Reply-To: <4E7C5DC3.8030409@alum.mit.edu>

On Fri, Sep 23, 2011 at 6:21 AM, Michael Haggerty <mhagger@alum.mit.edu> wrote:

Show 20 quoted lines

> On 09/23/2011 12:39 AM, Junio C Hamano wrote:
>> [...] 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.
>
> I'm confused by this comment.
>
> If an auditing system can be subverted by altering .gitattributes, then
> I can do just as much harm by changing the .gitattributes in one commit
> and making the "nasty" change in a second.  So any rigorous auditing
> system based on .gitattributes would have to prevent me from committing
> modifications to .gitattributes, in which case my commit will be
> rejected anyway.
>
> If by "auditing" you mean other less rigorous checks to which exceptions
> are *allowed*, then it is preferable to add the exception in the same
> commit as the otherwise-offending content, and therefore it is
> *required* that the .gitattributes of the new tree be used when checking
> the contents of that tree.

Currently, an auditing hook that cares about attributes, and which runs in a bare repo, ignores the in-repo .gitattributes, considering only the attributes set outside of the repo.

So by making git care about .gitattributes in a bare repo, such a hook can suddenly be bypassed.

j.