{"thread":{"id":"55414","subject":"[Bug] worktree prune --expires","startedAt":"2021-03-30T19:00:44Z","lastAt":"2021-03-30T21:23:30Z","messageCount":3,"participants":["Randall S. Becker","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"420640","messageId":"011901d72596$e5ed8670$b1c89350$@nexbridge.com","threadId":"55414","inReplyTo":null,"subject":"[Bug] worktree prune --expires","fromName":"Randall S. Becker","fromEmail":"rsbecker@nexbridge.com","sentAt":"2021-03-30T19:00:00Z","receivedAt":"2021-03-30T19:00:44Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"Hi Team,\n\nThis is pretty much just a quibble, but the command parser for worktree\nprune --expires should really report when a timestamp is invalid. For\nexample:\n\nworktree prune --expires A:30 actually\n\nactually appears to process the prune going back a very long time instead of\nreporting that A:30 isn't a good timestamp.\n\nExperienced using git 2.29.2 in Cygwin - not my usual space and git 2.31.0\non NonStop.\n\nI suspect that this should use the same timestamp parse as for other\ncommands, although I also noticed that git log --since accepts the same\nsyntactically awkward time. Am I missing something?\n\nThanks,\nRandall\n\n\n-- Brief whoami:\n NonStop developer since approximately 211288444200000000\n UNIX developer since approximately 421664400\n-- In my real life, I talk too much.\n\n\n"},{"id":"420651","messageId":"xmqqim58cpqa.fsf@gitster.g","threadId":"55414","inReplyTo":"011901d72596$e5ed8670$b1c89350$@nexbridge.com","subject":"Re: [Bug] worktree prune --expires","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-03-30T21:10:21Z","receivedAt":"2021-03-30T21:11:30Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Randall S. Becker\" <rsbecker@nexbridge.com> writes:\n\n> This is pretty much just a quibble, but the command parser for worktree\n> prune --expires should really report when a timestamp is invalid. For\n> example:\n>\n> worktree prune --expires A:30 actually\n\nAssuming that you had \"git\" in front, and spelled \"--expire\" without\nthe extra 's':\n\n$ git worktree prune --expire no.such.date\nfatal: malformed expiration date 'no.such.date'\n\nSo apparently, \"A:30\" is taken as a expiration date that is not\nmalformed.\n\n$ git rev-parse --since=A:30 --until=now\n--max-age=1617138312\n--min-age=1617138312\n\nAppears to show that A:30 is interpreted as the same as 'now', but\nthta is an unlucky coincidence of the day.\n\nWhat happens in this case is that \"A:\" is discarded as cruft (just\nlike dots are discarded in \"git log --since=8.days.ago\"), and only\nthe \"30\" takes effect of filling an unspecified \"date of the month\"\n[*1*].  And then the remainder is taken from the wallclock time, and\nthat is how the above \"rev-parse\" shows the same for A:30 and now,\nas it is the 30th of the month for me right now.\n\n$ git rev-parse --since=A:31 --until=now\n--max-age=1617224881\n--min-age=1617138481\n\ngives me the same time tomorrow (for the same reason that today's\n30th for me).\n\n\n[Footnote]\n\n*1* In A:30, there is no \"date of month\", \"month\", \"year\",\netc. specified, so we start from all unspecified, take the first\nnumber that is discovered (i.e. 30) and fill \"date of the month\"\nwith it.\n\n"},{"id":"420653","messageId":"011f01d725aa$cb807360$62815a20$@nexbridge.com","threadId":"55414","inReplyTo":"xmqqim58cpqa.fsf@gitster.g","subject":"RE: [Bug] worktree prune --expires","fromName":"Randall S. Becker","fromEmail":"rsbecker@nexbridge.com","sentAt":"2021-03-30T21:22:26Z","receivedAt":"2021-03-30T21:23:30Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On March 30, 2021 5:10 PM, Junio C Hamano wrote:\n> To: Randall S. Becker <rsbecker@nexbridge.com>\n> Cc: git@vger.kernel.org\n> Subject: Re: [Bug] worktree prune --expires\n> \n> \"Randall S. Becker\" <rsbecker@nexbridge.com> writes:\n> \n> > This is pretty much just a quibble, but the command parser for\n> > worktree prune --expires should really report when a timestamp is\n> > invalid. For\n> > example:\n> >\n> > worktree prune --expires A:30 actually\n> \n> Assuming that you had \"git\" in front, and spelled \"--expire\" without the\nextra\n> 's':\n\nYes, it was. I just transcribed it badly.\n\n> $ git worktree prune --expire no.such.date\n> fatal: malformed expiration date 'no.such.date'\n> \n> So apparently, \"A:30\" is taken as a expiration date that is not malformed.\n> \n> $ git rev-parse --since=A:30 --until=now\n> --max-age=1617138312\n> --min-age=1617138312\n> \n> Appears to show that A:30 is interpreted as the same as 'now', but thta is\nan\n> unlucky coincidence of the day.\n> \n> What happens in this case is that \"A:\" is discarded as cruft (just like\ndots are\n> discarded in \"git log --since=8.days.ago\"), and only the \"30\" takes effect\nof\n> filling an unspecified \"date of the month\"\n> [*1*].  And then the remainder is taken from the wallclock time, and that\nis\n> how the above \"rev-parse\" shows the same for A:30 and now, as it is the\n> 30th of the month for me right now.\n> \n> $ git rev-parse --since=A:31 --until=now\n> --max-age=1617224881\n> --min-age=1617138481\n> \n> gives me the same time tomorrow (for the same reason that today's 30th for\n> me).\n> \n> \n> [Footnote]\n> \n> *1* In A:30, there is no \"date of month\", \"month\", \"year\", etc. specified,\nso\n> we start from all unspecified, take the first number that is discovered\n(i.e. 30)\n> and fill \"date of the month\"\n> with it.\n\nWell, sounds a bit like an elbow test situation. The question is, what to do\nabout it, if anything, I suppose. I didn't even put the \"30\" in context\nwhile testing. Oops.\n\n"}]}