I'm generally very happy with the fuzzy parsing. It's a great feature
that is designed to and in general does save users a lot of time and
thought. In this case I don't think it does. The problems are:
(1) It's not ignoring things it can't understand, it's silently
interpreting them in a useless way. I'm pretty sure that "n units ago"
is equivalent to "the same time of day on the last day of the previous
month, plus n days."
(2) Though in some cases it's really obvious, in others it's quite
possible not to notice, e.g. if `git rev-list --since=5.dyas.ago` is
silently the same as `git rev-list --since=4.days.ago`.

So I do think it's worth improving. (Yes, I know, send patches; I'll
think about it.)

On Thu, Sep 6, 2012 at 1:36 PM, Junio C Hamano <gits...@pobox.com> wrote:
> Jeffrey Middleton <jefr...@gmail.com> writes:
>> In telling someone what date formats git accepts, and how to verify it
>> understands, I noticed this weirdness:
>> $ export TEST_DATE_NOW=`date -u +%s --date='September 10'`;
>> ./test-date approxidate now; for i in `seq 1 10`; do ./test-date
>> approxidate "$i frobbles ago"; done
>> now -> 2012-09-10 00:00:00 +0000
>> 1 frobbles ago -> 2012-09-02 00:00:00 +0000
>> ...
>> 10 frobbles ago -> 2012-09-11 00:00:00 +0000
>> Which gets more concerning once you realize the same thing happens no
>> matter what fake unit of time you use... including things like "yaers"
>> and "moths". Perhaps approxidate could be a little stricter?
> "Could be stricter", perhaps.
> Do we care deeply?  I doubt it, and for a good reason.  The fuzzy
> parsing is primarily [*1*] for humans getting interactive results
> who are expected to be able to notice when the fuzziness went far
> off.
> As long as we have ways for scripts and humans to feed its input in
> a more strict and unambiguous way [*2*], it does not hurt anybody if
> the fuzzy parser ignored crufts that it does not understand.
> [Footnotes]
> *1* ... and of course some coding fun and easter egg values. Think
> of it as our own Eliza or Zork parser ;-).
> *2* And of course we do.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to