From: Tuomas Ahola <taahol@utu.fi>
To: Junio C Hamano <gitster@pobox.com>
Cc: <git@vger.kernel.org>, Jeff King <peff@peff.net>
Subject: Re: [PATCH v3 2/4] approxidate: alias "today" to "now"
Date: Fri, 15 May 2026 08:02:43 +0300 [thread overview]
Message-ID: <20260515050243.daahz%taahol@utu.fi> (raw)
In-Reply-To: <xmqqa4u1e9k9.fsf@gitster.g>
Junio C Hamano <gitster@pobox.com> wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
> > Tuomas Ahola <taahol@utu.fi> writes:
> >
> >> Junio C Hamano <gitster@pobox.com> wrote:
> >>
> >>> Tuomas Ahola <taahol@utu.fi> writes:
> >>>
> >>> > Sorry, I don't know if I understood. Does the patch change the behavior of
> >>> > that command somehow? Is there some kind of edge case I missed?
> >>>
> >>> No, I did not think it was a good idea to carve the behaviour in
> >>> stone that "git log --since=today" behaves as if it were given "git
> >>> log --since=now". My reaction would have been very different if we
> >>> were deliberatly and explicitly saying "today is synonym for now",
> >>> but the thing is, it is not a designed behaviour but what
> >>> approxidate does for anything it does not understand, e.g.
> >>>
> >>> git log --since=decay
> >>> git log --since=bogus
> >>>
> >>> all behave as if it were given --since=now.
> >>
> >> Thanks for spelling that out. So, as there is no deliberative
> >> decision behind the current behaviour of "today", the code has
> >> to remain non-committed on that; we are not at liberty to codify
> >> the status quo. Right?
> >
> > Not right. It is more like "Even though we try not to change
> > existing behavoiur left and right without a good reason to avoid
> > breaking existing users' expectations, we should be able to "fix"
> > what is not intended behaviour but is something the code happened to
> > be doing, especially if the current behaviour does not make sense.
Well, that's not far off from what I wrote. I just meant we cannot
make the current (somewhat accidental) behaviour official *just because*
it happens to be the status quo.
>
> And the other half of the discussion is that once we explicitly say "today
> means right now" and make it official, it makes it much harder to fix it
> later. So we need to be very careful in our first attempt.
Roger that.
next prev parent reply other threads:[~2026-05-15 5:02 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-18 18:01 [PATCH 0/2] approxidate: tweak special date formats Tuomas Ahola
2025-03-18 18:02 ` [PATCH 1/2] approxidate: make "specials" respect fixed day-of-month Tuomas Ahola
2025-04-04 8:19 ` Jeff King
2025-03-18 18:02 ` [PATCH 2/2] approxidate: overwrite tm_mday for `now` and `yesterday` Tuomas Ahola
2025-04-04 8:40 ` Jeff King
2026-05-12 14:54 ` [PATCH v2 0/3] approxidate: tweak special date formats Tuomas Ahola
2026-05-12 14:54 ` [PATCH v2 1/3] t0006: add support for approxidate test date adjustment Tuomas Ahola
2026-05-12 16:34 ` Junio C Hamano
2026-05-12 18:35 ` Jeff King
2026-05-12 14:54 ` [PATCH v2 2/3] approxidate: make "specials" respect fixed day-of-month Tuomas Ahola
2026-05-12 16:52 ` Junio C Hamano
2026-05-12 14:54 ` [PATCH v2 3/3] approxidate: use deferred mday adjustments for "specials" Tuomas Ahola
2026-05-14 11:55 ` [PATCH v3 0/4] approxidate: tweak special date formats Tuomas Ahola
2026-05-14 11:55 ` [PATCH v3 1/4] t0006: add support for approxidate test date adjustment Tuomas Ahola
2026-05-14 11:55 ` [PATCH v3 2/4] approxidate: alias "today" to "now" Tuomas Ahola
2026-05-14 15:36 ` Junio C Hamano
2026-05-14 21:07 ` Tuomas Ahola
2026-05-15 1:27 ` Junio C Hamano
2026-05-15 1:38 ` Junio C Hamano
2026-05-15 5:02 ` Tuomas Ahola [this message]
2026-05-14 11:55 ` [PATCH v3 3/4] approxidate: make "specials" respect fixed day-of-month Tuomas Ahola
2026-05-14 16:06 ` Junio C Hamano
2026-05-14 11:55 ` [PATCH v3 4/4] approxidate: use deferred mday adjustments for "specials" Tuomas Ahola
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=20260515050243.daahz%taahol@utu.fi \
--to=taahol@utu.fi \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--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