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

Michael Haggerty [off-list ref] 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!

So even though I agree with you that the check mechanism may need to be
aware of what revision it is checking and adjust which rules are applied
when checking the revision, I do not think using in-tree attribute file is
the right solution to that problem.

On 09/22/2011 07:26 PM, Junio C Hamano wrote:

Michael Haggerty [off-list ref] writes:

quoted

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.

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/

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

From: "Michael Haggerty" <redacted>
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:

quoted

Michael Haggerty [off-list ref] writes:

quoted

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

On 09/23/2011 02:49 PM, Stephen Bash wrote:

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?

I want to avoid code churn, especially in third-party code.  With your
solution, I believe that we would be forced to entirely clean up any
file that we needed to touch.  The resulting code churn would make
integrating future upstream releases a nightmare.

For some kinds of checks, one could only check that the *lines* changed
satisfy the new rules.

But rather than thinking up workarounds, it seems like a better idea to
fix git to handle .gitattributes correctly.

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/