All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Bash <bash@genarts.com>
To: Michael Haggerty <mhagger@alum.mit.edu>
Cc: git discussion list <git@vger.kernel.org>,
	Jay Soffian <jaysoffian@gmail.com>, Jeff King <peff@peff.net>,
	Jakub Narebski <jnareb@gmail.com>,
	Junio C Hamano <gitster@pobox.com>
Subject: Re: How to use git attributes to configure server-side checks?
Date: Fri, 23 Sep 2011 08:49:08 -0400 (EDT)	[thread overview]
Message-ID: <33047451.27244.1316782148569.JavaMail.root@mail.hq.genarts.com> (raw)
In-Reply-To: <4E7C44C8.10000@alum.mit.edu>

----- Original Message -----
> 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

  reply	other threads:[~2011-09-23 12:49 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-21 19:32 How to use git attributes to configure server-side checks? Michael Haggerty
2011-09-21 20:02 ` Jay Soffian
2011-09-21 20:17 ` Junio C Hamano
2011-09-22  8:28   ` Michael Haggerty
2011-09-22 15:41     ` Jay Soffian
2011-09-22 17:13       ` Jeff King
2011-09-22 18:41         ` Jay Soffian
2011-09-22 19:22           ` Junio C Hamano
2011-09-22 20:58           ` Jeff King
2011-09-22 21:04             ` Jeff King
2011-09-23 10:06             ` Michael Haggerty
2011-09-23 19:33               ` Jeff King
2011-09-23 19:40                 ` Junio C Hamano
2011-09-23 19:44                   ` Jeff King
2011-09-24  6:05                 ` Michael Haggerty
2011-09-24  6:15                   ` Jeff King
2011-09-24 11:03                     ` Michael Haggerty
2011-09-26  4:09                       ` Junio C Hamano
2011-09-26  4:28                         ` Michael Haggerty
2011-09-26 11:05                       ` Jeff King
2011-09-26 14:14                         ` Jakub Narebski
2011-09-26 15:11                         ` Michael Haggerty
2011-09-22 17:26     ` Junio C Hamano
2011-09-23  8:35       ` Michael Haggerty
2011-09-23 12:49         ` Stephen Bash [this message]
2011-09-23 13:31           ` Michael Haggerty
2011-09-22 22:54     ` Jakub Narebski
2011-09-23 10:38       ` Michael Haggerty
2012-02-17 18:42   ` Michael Haggerty
2012-02-17 19:26     ` Junio C Hamano
2012-02-17 19:59       ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=33047451.27244.1316782148569.JavaMail.root@mail.hq.genarts.com \
    --to=bash@genarts.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jaysoffian@gmail.com \
    --cc=jnareb@gmail.com \
    --cc=mhagger@alum.mit.edu \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.