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

From: Jeff King <peff@peff.net>
Date: Apr 20, 2011, 06:43 UTC
Message-ID: <20110420064318.GF28597@sigill.intra.peff.net>
In-Reply-To: <0f30e048-7dd2-4aff-8c1f-00bf0dfa3d34-mfwitten@gmail.com>

On Wed, Apr 20, 2011 at 02:53:36AM +0000, Michael Witten wrote:

Show 15 quoted lines

> One of the possible values for a date format is `local', which
> specifies that a date should be output as though the date format
> were instead `default' but in terms of the user's time zone
> instead of the time zone stored by git; clearly, then, `local'
> does not really provide just another format, but rather the
> combination of 2 specifications:
> 
>   * A format for the date (`default')
>   * A time zone in which to interpret the date (`local', if you will)
>
> [...]
>
> This patch series reimplements the original purpose of `--date' by allowing
> the time zone mode to be specified independently of the date format
> (see the commit message for [2] and the documentation provided by [3]):

I think the intent of this series is good. See also this thread from quite a while back:

  http://article.gmane.org/gmane.comp.version-control.git/112026

> The date format `local' has thus been deprecated, though it is still
> supported (with a warning on stderr).

I don't know if we need to go that far. We can leave it forever as a historical compatibility feature. Its existence is not really hurting anyone as long as the documentation marks it as deprecated (or doesn't even mention it).

> These patches apply cleanly to the current tip of Junio's `next' branch:

Why not "master"? Usually we try to develop features independently on top of master, and then merge them. That way topics can graduate independently to master, and it is easier to see which topics are responsible for breakages. If you really need something in another topic (because you are directly building on it, or the merge would just be too painful), then build straight on that topic's commits, not on top of next (and of course tell everyone which topic it's built on).

> 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 (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).

-Peff