* [Bug] worktree prune --expires @ 2021-03-30 19:00 Randall S. Becker 2021-03-30 21:10 ` Junio C Hamano 0 siblings, 1 reply; 3+ messages in thread From: Randall S. Becker @ 2021-03-30 19:00 UTC (permalink / raw) To: git Hi Team, 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 actually appears to process the prune going back a very long time instead of reporting that A:30 isn't a good timestamp. Experienced using git 2.29.2 in Cygwin - not my usual space and git 2.31.0 on NonStop. I suspect that this should use the same timestamp parse as for other commands, although I also noticed that git log --since accepts the same syntactically awkward time. Am I missing something? Thanks, Randall -- Brief whoami: NonStop developer since approximately 211288444200000000 UNIX developer since approximately 421664400 -- In my real life, I talk too much. ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Bug] worktree prune --expires 2021-03-30 19:00 [Bug] worktree prune --expires Randall S. Becker @ 2021-03-30 21:10 ` Junio C Hamano 2021-03-30 21:22 ` Randall S. Becker 0 siblings, 1 reply; 3+ messages in thread From: Junio C Hamano @ 2021-03-30 21:10 UTC (permalink / raw) To: Randall S. Becker; +Cc: git "Randall S. Becker" <rsbecker@nexbridge.com> 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. ^ permalink raw reply [flat|nested] 3+ messages in thread
* RE: [Bug] worktree prune --expires 2021-03-30 21:10 ` Junio C Hamano @ 2021-03-30 21:22 ` Randall S. Becker 0 siblings, 0 replies; 3+ messages in thread From: Randall S. Becker @ 2021-03-30 21:22 UTC (permalink / raw) To: 'Junio C Hamano'; +Cc: git On March 30, 2021 5:10 PM, Junio C Hamano wrote: > To: Randall S. Becker <rsbecker@nexbridge.com> > Cc: git@vger.kernel.org > Subject: Re: [Bug] worktree prune --expires > > "Randall S. Becker" <rsbecker@nexbridge.com> 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': 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. ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2021-03-30 21:23 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-03-30 19:00 [Bug] worktree prune --expires Randall S. Becker 2021-03-30 21:10 ` Junio C Hamano 2021-03-30 21:22 ` Randall S. Becker
Code repositories for project(s) associated with this public inbox https://80x24.org/mirrors/git.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).