Date: Tue, 17 Jan 2012 12:38:38 -0500
From: Austin Clements <amdragon@MIT.EDU>
To: Tomi Ollila <tomi.ollila@iki.fi>
Subject: Re: [PATCH 2/3] emacs: whitespace-cleanup and indent-region for
	emacs/*.el files
Message-ID: <20120117173838.GN16740@mit.edu>
References: <cun7h0v7ete.fsf@hotblack-desiato.hh.sledj.net>
	<1326704656-26102-1-git-send-email-tomi.ollila@iki.fi>
	<1326704656-26102-2-git-send-email-tomi.ollila@iki.fi>
	<20120117043200.GJ16740@mit.edu> <yf6obu261z4.fsf@taco2.nixu.fi>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <yf6obu261z4.fsf@taco2.nixu.fi>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: notmuch@notmuchmail.org
Precedence: list

Quoth Tomi Ollila on Jan 17 at 12:46 pm:
> On Mon, 16 Jan 2012 23:32:00 -0500, Austin Clements <amdragon@mit.edu> wrote:
> > Cleanup is the type of pain that should only be suffered once, so I'd
> > be much happier with this if there was an accompanying git hook that
> > prevented more mis-formatted code from slipping in.
> 
> We'd need a script to be called from .git/hooks/pre-commit to do
> extra checking; developer needs first activate this pre-commit
> and then add call to our checking routine. Imagine the amount
> of false positives this hook starts to generate...

It's unfortunate (but sensible) that git doesn't provide an automatic
way to set up verify scripts like this, but that doesn't mean we can't
make it easy.  Put a script in devel (or whatever it winds up being
called) that can be sourced from the pre-commit hook and then mention
this in HACKING.

Why it would generate false positives, assuming the cleanup goes in at
the same time the hook goes in (or the script is somehow clever enough
to only check changed lines)?

> ... but. developer can run 'git commit --no-verify' ...aargh no;
> I guess if pre-commit hook fails, commit-msg hook is not run
> and this is bypassed; maybe NO_FORMATCHECK_HOOK=1 git commit ...
> is the answer.

Maybe the script could generate a warning/prompt, rather than
preventing the commit altogether?

> But what we at least need is Guidelines document that states 
> these formatting issues clearly and precicely. Surely 
> self-respecting programmers understands to follow there (and soon 
> adjusts their workflow -- i.e. activate/run these checkers
> after list response).

I think the guidelines for elisp are pretty well known.  I agree that
we need such a document for the C/C++ code.  I started writing one a
while ago, but other things took over before I got very far.