----- Original Message ----- > From: "Michael Haggerty" <mhagger@xxxxxxxxxxxx> > 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@xxxxxxxxxxxx> 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 -- 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