On Sat, Oct 14, 2023 at 09:27:27AM -0700, Junio C Hamano wrote: > Jacob Stopak <jacob@xxxxxxxxxxxxxxxx> writes: > > Is "postfix" a verb that is commonly understood? I would say > "append" would be understood by more readers. It's probably true that "append" or "suffix" (which is used in the code) would be more easily understood. I'll switch in my updated messages. > Also, is "calendar" > hour different from other kinds of hours, perhaps stopwatch hours > and microwave-oven hours? Lol! By saying "calendar" I mean "falling on the official boundaries of", like 11:15:00 - 11:16:00. Unlike the time between 11:15:30 - 11:16:30 which is also a minute, but it's not a "calendar" minute because it overlaps into the next minute. I guess in this case it's more of a "clock" minute than a "calendar" minute though ':D... I guess "calendar" terminology is used more for months/years... > I personally do not think it is a problem, simply because a quality > bug report that would capture information necessary to diagnose any > issue concisely in a readable fashion would take at least 90 seconds > or more to produce, though. This is true, when the user intentionally opens the bugreport with the intent to start filling it out immediately, I assume they would almost always cross the minute barrier and avoid the issue. However, there are edge cases like the one I outlined, where the user might open and close the report quickly, followed by rerunning the command. This could be someone learning to use the command for the first time. Or the case where a user only fills in a small part of the report before closing it and running the command again. These cases are certainly "the exception" but it seems the program could be a bit more consistent/intuitive when they do occur. > Instead of lengthening the filename for all files by 2 digits, the > command can retry by adding say "+1", "+2", etc. after the failed > filename to find a unique suffix within the same minute. It would > mean that after writing git-bugreport-2023-10-14-0920.txt and you > start another one without spending enough time, the new one may > become git-bugreport-2023-10-14-0920+1.txt or something unique. It > would be really unlikely that you would run out after failing to > find a vacant single digit suffix nine times, i.e. trying "+9". It > would also help preserve existing user's workflow, e.g. they may > have written automation that assumes the down-to-minute format and > it would keep working on their bug reports without breaking. I agree with all of this, and to me it's a better solution than _appending_ the second value :). I have a patchset almost ready for this so I'll try to submit it later tonight.
