From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Thien-Thi Nguyen Newsgroups: gmane.lisp.guile.devel Subject: Re: rfc: (add-hook 'before-save-hook 'delete-trailing-whitespace) Date: Sat, 23 Jan 2010 01:38:30 +0100 Message-ID: <87636tr6yh.fsf@ambire.localdomain> References: <87d41ewezl.fsf@ambire.localdomain> <87eilj2nkt.fsf@ossau.uklinux.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1264208946 19511 80.91.229.12 (23 Jan 2010 01:09:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 23 Jan 2010 01:09:06 +0000 (UTC) To: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sat Jan 23 02:08:59 2010 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1NYUSP-0005Fe-IF for guile-devel@m.gmane.org; Sat, 23 Jan 2010 02:08:57 +0100 Original-Received: from localhost ([127.0.0.1]:57813 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NYURz-0000w1-JX for guile-devel@m.gmane.org; Fri, 22 Jan 2010 20:06:07 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NYURv-0000vX-Tv for guile-devel@gnu.org; Fri, 22 Jan 2010 20:06:03 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NYURv-0000v2-4V for guile-devel@gnu.org; Fri, 22 Jan 2010 20:06:03 -0500 Original-Received: from [199.232.76.173] (port=60692 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NYURu-0000uv-Mp for guile-devel@gnu.org; Fri, 22 Jan 2010 20:06:02 -0500 Original-Received: from mx20.gnu.org ([199.232.41.8]:37797) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NYURu-0006Ul-1c for guile-devel@gnu.org; Fri, 22 Jan 2010 20:06:02 -0500 Original-Received: from host77-67-dynamic.30-79-r.retail.telecomitalia.it ([79.30.67.77] helo=ambire.localdomain) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NYURb-0000tB-66 for guile-devel@gnu.org; Fri, 22 Jan 2010 20:05:43 -0500 Original-Received: from ttn by ambire.localdomain with local (Exim 4.63) (envelope-from ) id 1NYU1G-0004Ek-RL for guile-devel@gnu.org; Sat, 23 Jan 2010 01:38:30 +0100 In-Reply-To: <87eilj2nkt.fsf@ossau.uklinux.net> (Neil Jerram's message of "Thu, 21 Jan 2010 20:46:26 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.91 (gnu/linux) X-detected-operating-system: by mx20.gnu.org: Genre and OS details not recognized. X-Greylist: delayed 1474 seconds by postgrey-1.27 at nadesico; Fri, 22 Jan 2010 20:05:43 EST X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:9914 Archived-At: () Neil Jerram () Thu, 21 Jan 2010 20:46:26 +0000 > Jim Meyering gives a nice rationale in > . I'm afraid those rationales don't persuade me: [...] Well, i respect the work Jim Meyering does and read his rationale w/ a more general mindset. I agree Guile is not GNU coreutils, and have elided the "does not apply" parts, w/ the exception of: > [merge conflicts] Hasn't been a problem in practice AFAIK. I've been doing a lot of merging at work recently, with a lot of real merge conflicts. The few that are caused by whitespace are easy to spot, and give me a pleasant interlude between the ones that are really difficult. If there is a whitespace policy, we can eliminate those conflicts (by rejecting non-compliant patches). This is good! If you are concerned that your hook is going to generate diffs that other developers might think are spurious - I'd say don't worry about that. I personally won't object to that, and I don't think Andy or Ludo would either. I would rather clarify the policy (either way) and then adopt it, than go w/o policy. If the policy (either way) is clear, i know how to avoid introducing spurious diffs and being inconvenienced by them from others, and can help others do the same. If you anticipate some other practical problem, can you say more about what it is? The practical problem is that w/o policy spurious diffs come and go, instead of being addressed once (one-shot big-commit if policy is "deny", a blurb in HACKING to justly orient newbies if "allow"). This is "practical" in the sense of "what people will do in practice". It is a "problem" in the sense of "i hate burning my geezer brain-cells on administrivia over and over and over...". Revised proposal: Let's decide one way or the other, record the decision (including link to this thread), and bask in the time and effort saved by our forward thinking when the issue resurfaces w/ new programmers. thi