"Randall S. Becker" [off-list ref] writes:
This is pretty much just a quibble, but the command parser for worktree
prune --expires should really report when a timestamp is invalid. For
example:
worktree prune --expires A:30 actually
Assuming that you had "git" in front, and spelled "--expire" without
the extra 's':
$ git worktree prune --expire no.such.date
fatal: malformed expiration date 'no.such.date'
So apparently, "A:30" is taken as a expiration date that is not
malformed.
$ git rev-parse --since=A:30 --until=now
--max-age=1617138312
--min-age=1617138312
Appears to show that A:30 is interpreted as the same as 'now', but
thta is an unlucky coincidence of the day.
What happens in this case is that "A:" is discarded as cruft (just
like dots are discarded in "git log --since=8.days.ago"), and only
the "30" takes effect of filling an unspecified "date of the month"
[*1*]. And then the remainder is taken from the wallclock time, and
that is how the above "rev-parse" shows the same for A:30 and now,
as it is the 30th of the month for me right now.
$ git rev-parse --since=A:31 --until=now
--max-age=1617224881
--min-age=1617138481
gives me the same time tomorrow (for the same reason that today's
30th for me).
[Footnote]
*1* In A:30, there is no "date of month", "month", "year",
etc. specified, so we start from all unspecified, take the first
number that is discovered (i.e. 30) and fill "date of the month"
with it.
On March 30, 2021 5:10 PM, Junio C Hamano wrote:
To: Randall S. Becker <redacted>
Cc: git@vger.kernel.org
Subject: Re: [Bug] worktree prune --expires
"Randall S. Becker" [off-list ref] writes:
quoted
This is pretty much just a quibble, but the command parser for
worktree prune --expires should really report when a timestamp is
invalid. For
example:
worktree prune --expires A:30 actually
Assuming that you had "git" in front, and spelled "--expire" without the
extra
's':
Yes, it was. I just transcribed it badly.
$ git worktree prune --expire no.such.date
fatal: malformed expiration date 'no.such.date'
So apparently, "A:30" is taken as a expiration date that is not malformed.
$ git rev-parse --since=A:30 --until=now
--max-age=1617138312
--min-age=1617138312
Appears to show that A:30 is interpreted as the same as 'now', but thta is
an
unlucky coincidence of the day.
What happens in this case is that "A:" is discarded as cruft (just like
dots are
discarded in "git log --since=8.days.ago"), and only the "30" takes effect
of
filling an unspecified "date of the month"
[*1*]. And then the remainder is taken from the wallclock time, and that
is
how the above "rev-parse" shows the same for A:30 and now, as it is the
30th of the month for me right now.
$ git rev-parse --since=A:31 --until=now
--max-age=1617224881
--min-age=1617138481
gives me the same time tomorrow (for the same reason that today's 30th for
me).
[Footnote]
*1* In A:30, there is no "date of month", "month", "year", etc. specified,
so
we start from all unspecified, take the first number that is discovered
(i.e. 30)
and fill "date of the month"
with it.
Well, sounds a bit like an elbow test situation. The question is, what to do
about it, if anything, I suppose. I didn't even put the "30" in context
while testing. Oops.