On Thu, Mar 05, 2009 at 02:21:27PM -0800, Junio C Hamano wrote:
> Jeff King <peff@xxxxxxxx> writes:
>
> > Yep, it is more invasive. But I consider it more maintainable in the
> > long run.
>
> Why do you think it is more confusing to ask "--date=local --date=iso"
> than asking "--local-time --date=iso"? If the patch under discussion were
> not mine, I would have said that --date=local that flips the "lie about
> timezone" bit and tells us to use the "default" format is a brilliant and
> elegant solution.
Because from the user's perspective --foo={bar,baz,bleep} is about
selecting exactly one of {bar,baz,bleep}. Having --date=local is like
having --pretty=abbrev-commit. Yes, it is vaguely related to date
display, but it is orthogonal to the selection of one of the mutually
exclusive options.
Maybe I am alone in viewing the options this way. But at the very least,
the documentation that reads:
--date={relative,local,default,iso,rfc,short}
should be updated to show that _some_ options are mutually exclusive but
others are not.
> I honestly do not see the point of what you are proposing to make
> "selector" and "format" independent; unless you are shooting for
> "--use-tz=Indian/Christmas --date=iso", that is.
No, I am not really proposing --use-tz as I have no use for it. But it
is an example of why syntactically keeping the orthogonal concept of
"which timezone to use" away from "which date style to use" is useful.
The only reason --date=local _doesn't_ look terrible is that it is a
simple boolean. Any date-related flags that took an argument would look
stupid as --date=option=foo.
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
