As you mentioned, parsing "n ... [month]", and even "...n..." (e.g.
"the 3rd") as the nth day of a month is great, but in this case, I
think "n ... ago" is a pretty strong sign that that's not the intended
My first thought was just to make it an error if the string ends in
"ago" but the date is parsed as a day of the month. You don't actually
have to come up with any typos to blacklist, just keep the "ago" from
being silently ignored. I suspect "n units ago" is by far the most
common use of the approxidate parsing in the wild, since it's
documented and has been popularized online. So throwing an error just
in that case would save essentially everyone. I hadn't even realized
it worked without "ago" until I looked at the code.
If that doesn't sound like a good plan, then yes, I agree, it'd be
tricky to catch it in the general case without breaking things.
(Levenshtein distance to the target strings instead of exact matching,
I guess, so that it could say "did you mean..." like for misspelled
On Fri, Sep 7, 2012 at 6:54 AM, Jeff King <p...@peff.net> wrote:
> On Thu, Sep 06, 2012 at 02:01:30PM -0700, Jeffrey Middleton wrote:
> > 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.
> Right, but we would then need to come up with a list of things it _does_
> understand. So right now I can say "6 June" or "6th of June" or even "6
> de June", and it works because we just ignore the cruft in the middle.
> So I think you'd need to either whitelist what everybody is typing, or
> blacklist some common typos (or convince people to be stricter in what
> they type).
> > So I do think it's worth improving. (Yes, I know, send patches; I'll
> > think about it.)
> You read my mind. :)
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