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

From: Stephen Bash <bash@genarts.com>
Date: Sep 23, 2011, 12:49 UTC
Message-ID: <33047451.27244.1316782148569.JavaMail.root@mail.hq.genarts.com>
In-Reply-To: <4E7C44C8.10000@alum.mit.edu>

----- Original Message -----

Show 23 quoted lines

> From: "Michael Haggerty" <mhagger@alum.mit.edu>
> Sent: Friday, September 23, 2011 4:35:20 AM
> Subject: Re: How to use git attributes to configure server-side checks?
>
> On 09/22/2011 07:26 PM, Junio C Hamano wrote:
> > Michael Haggerty <mhagger@alum.mit.edu> writes:
> >
> >> I would like the checking configuration to be *versioned* along with the
> >> code. For example, suppose my project decides to enforce a rule that
> >> all Python code needs to be indented with spaces. It might be that not
> >> all of our old code adheres to this rule, and that we only want to clean
> >> up the code in master.
> >
> > You want to sneak in a badly formatted code? Add an entry to the
> > in-tree attributes file to disable whitespace checking to cover that file!
> 
> No, the scenario that I was trying to describe is a project that wants
> to tighten up its code formatting rules after years of laxity. It is
> convenient to support legacy branches that still contain nonconforming
> code without having to reformat it all, just as it is convenient to
> fix the current code incrementally rather than requiring all of the
> cleanup to be done in one big bang. Thus it is important that new rules not be
> enforced retroactively on old code.

We're in the process of a similar change over (we're dealing with EOL rather than indents), but I attacked it from a different angle...  I wrote our update script to examine modified files and ensure compliance (diff-tree -r, iterate over blobs).  That way legacy files are left alone (even in master), but active development must live up to the current rules.  Is there a reason you need to go tree-by-tree rather than file-by-file?

Thanks, Stephen