From: Michael Witten <mfwitten@gmail.com>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org
Subject: Re: [RFC 0/5] Date Mode: Add --time-zone; deprecate --date=local
Date: Wed, 20 Apr 2011 14:23:37 +0000 [thread overview]
Message-ID: <d74e95d4-ef16-42fb-ae8f-b1d7a8b9d91e-mfwitten@gmail.com> (raw)
In-Reply-To: <20110420064318.GF28597@sigill.intra.peff.net>
On Wed, 20 Apr 2011 02:43:18 -0400, Jeff King wrote:
>> 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.
next prev parent reply other threads:[~2011-04-20 14:28 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-20 2:53 [RFC 0/5] Date Mode: Add --time-zone; deprecate --date=local Michael Witten
2011-04-20 2:45 ` [RFC 1/5] Light refactoring of date infrastructure Michael Witten
2011-04-20 2:45 ` [RFC 2/5] Pretty Print: show tz when using DATE_LOCAL Michael Witten
2011-04-21 22:34 ` Junio C Hamano
2011-04-22 14:08 ` Dates in Commits and other issues of style (Re: [RFC 2/5] Pretty Print: show tz when using DATE_LOCAL) Michael Witten
2011-04-25 1:26 ` Miles Bader
2011-04-25 3:57 ` Junio C Hamano
2011-04-25 10:45 ` Jakub Narebski
2011-04-25 18:29 ` Junio C Hamano
2011-04-22 14:36 ` [RFC 2/5] Pretty Print: show tz when using DATE_LOCAL Michael Witten
2011-04-22 15:06 ` Junio C Hamano
2011-04-20 2:45 ` [RFC 3/5] Date Mode: Implementation Michael Witten
2011-04-21 22:44 ` Junio C Hamano
2011-04-20 2:45 ` [RFC 4/5] Date Mode: Documentation Michael Witten
2011-04-20 2:45 ` [RFC 5/5] Date Mode: Tests Michael Witten
2011-04-21 22:44 ` Junio C Hamano
2011-04-23 3:42 ` Michael Witten
2011-04-23 5:06 ` Michael Witten
2011-04-23 3:45 ` Time zone option name (Re: [RFC 5/5] Date Mode: Tests) Michael Witten
2011-04-23 5:27 ` Junio C Hamano
2011-04-23 3:59 ` [RFC 5/5] Date Mode: Tests Michael Witten
2011-04-20 6:43 ` [RFC 0/5] Date Mode: Add --time-zone; deprecate --date=local Jeff King
2011-04-20 14:21 ` Michael Witten
2011-04-21 1:50 ` Junio C Hamano
2011-04-21 2:14 ` Michael Witten
2011-04-21 3:57 ` Junio C Hamano
2011-04-21 4:09 ` Michael Witten
2011-04-20 14:22 ` Michael Witten
2011-04-20 14:22 ` Michael Witten
2011-04-20 14:23 ` Michael Witten [this message]
2011-04-21 0:07 ` Tabs and spaces (Re: [RFC 0/5] Date Mode: Add --time-zone; deprecate --date=local) Jonathan Nieder
2011-04-21 1:51 ` Tabs and spaces Michael Witten
2011-04-21 2:18 ` Jonathan Nieder
2011-04-21 3:15 ` Michael Witten
2011-04-21 3:25 ` Thiago Farina
2011-04-21 10:46 ` Alex Riesen
2011-04-21 12:57 ` Michael Witten
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=d74e95d4-ef16-42fb-ae8f-b1d7a8b9d91e-mfwitten@gmail.com \
--to=mfwitten@gmail.com \
--cc=git@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).