Re: [RFC 0/5] Date Mode: Add --time-zone; deprecate --date=local

From: Michael Witten <mfwitten@gmail.com>
Date: Apr 20, 2011, 14:23 UTC
Message-ID: <d74e95d4-ef16-42fb-ae8f-b1d7a8b9d91e-mfwitten@gmail.com>
In-Reply-To: <20110420064318.GF28597@sigill.intra.peff.net>

On Wed, 20 Apr 2011 02:43:18 -0400, Jeff King wrote:

Show 13 quoted lines

>> There are some whitespace warnings (a la `git diff --check'), but I
>> have reviewed them and personally approve of them; if you think that
>> appraisal is incorrect, then you don't know what you're talking about :-P
>
> All of the warnings I saw are related to indentation with spaces, and it
> looks like your intent in each case is to line up the opening paren of a
> function call with a line of arguments below, like:
>
>   foo(bar, baz
>       bleep, moof);
>
> That's fine, style-wise, but the run of spaces should be collapsed into
> tabs followed by spaces, with each tab representing 8 spaces.

I understand this, as I've read:

  Documentation/CodingGuidelines

and I'm also responsible for this massive git flamewar of yore on the same subject:

  http://article.gmane.org/gmane.comp.version-control.git/61095
  Message-ID: 634393B0-734A-4884-93E3-42F7D3CB157F@mit.edu

However - and this is the key point - if you are going to be mixing tabs and spaces ANYWAY, then you might as well do it in a way that maintains alignment within a tab level regardless of the current setting for the tabwidth:

> (some would argue that it should be "one tab for each level of
> structural indentation, plus spaces to line up the arguments",
> but I don't find that we tend to follow such a rule in git).

That approach is the most logical and the most robust, and if somebody messes it up, then the whitespace simply reduces (or degenerates) back to just the very approach you espouse anyway.