| Message ID | 20231014040101.8333-1-jacob@initialcommit.io (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | bugreport: add 'seconds' to default outfile name | expand |
Hi Jacob
On Sat, Oct 14, 2023, at 06:01, Jacob Stopak wrote:
> This patch adds the calendar second value to the default bugreport
Nitpick: you can just say “Add the calendar”. “This patch” is redundant.
See `Documentation/SubmittingPatches` at `imperative-mood`.
Jacob Stopak <jacob@initialcommit.io> writes: > Currently, git bugreport postfixes the default bugreport filename (and > diagnostics zip filename if --diagnose is supplied) with the current > calendar hour and minute values, assuming the -s flag is absent. Is "postfix" a verb that is commonly understood? I would say "append" would be understood by more readers. Also, is "calendar" hour different from other kinds of hours, perhaps stopwatch hours and microwave-oven hours? > If a user runs the bugreport command more than once within a calendar > minute, a filename conflict with an existing file occurs and the program > errors, since the new output filename was already used for the previous > file. This is totally expected and you made an excellent observation. 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. 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.
On 2023-10-14 18:27, Junio C Hamano wrote: > Jacob Stopak <jacob@initialcommit.io> writes: >> If a user runs the bugreport command more than once within a calendar >> minute, a filename conflict with an existing file occurs and the >> program >> errors, since the new output filename was already used for the >> previous >> file. > > This is totally expected and you made an excellent observation. > > 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. > > 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. How about making the filename a bit shorter first, to make room for the additional two digits, so the example mentioned above would end up being named "git-bugreport-20231014-092037.txt"?
Dragan Simic <dsimic@manjaro.org> writes: > How about making the filename a bit shorter first, to make room for > the additional two digits, so the example mentioned above would end up > being named "git-bugreport-20231014-092037.txt"? The reason I stated not to unconditionally add two more digits is *not* that I wanted to keep things shorter. I wanted to keep names stable and in the same shape as before for sensible people who spend more than 60 seconds---only those who produce more than one within the same minute will be affected. What is your reason to want to make the filename shoter first? It would break everybody, wouldn't it?
On 2023-10-14 19:45, Junio C Hamano wrote: > Dragan Simic <dsimic@manjaro.org> writes: > >> How about making the filename a bit shorter first, to make room for >> the additional two digits, so the example mentioned above would end up >> being named "git-bugreport-20231014-092037.txt"? > > The reason I stated not to unconditionally add two more digits is > *not* that I wanted to keep things shorter. I wanted to keep names > stable and in the same shape as before for sensible people who spend > more than 60 seconds---only those who produce more than one within > the same minute will be affected. > > What is your reason to want to make the filename shoter first? > It would break everybody, wouldn't it? Please note that I haven't researched in detail what else depends on the current filename format, which presumably is a whole bunch of stuff, I just suggested this filename compaction because I understood that the filename length was becoming an issue. Speaking in general, I somehow find "20220712" a bit more readable than "2022-07-12" as part of a filename, but that's of course just my personal preference.
On Sat, Oct 14, 2023 at 09:27:27AM -0700, Junio C Hamano wrote: > Jacob Stopak <jacob@initialcommit.io> 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.
On Sat, Oct 14, 2023 at 07:52:32PM +0200, Dragan Simic wrote: > > Speaking in general, I somehow find "20220712" a bit more readable than > "2022-07-12" as part of a filename, but that's of course just my personal > preference. It's funny how we all have our own preferences for this kind of thing. Mine happens to be separating the date part from the rest of the filename with an underscore, but using a hyphen to separate individual date components like: filename_2022-07-12.ext
On 2023-10-15 05:07, Jacob Stopak wrote: > On Sat, Oct 14, 2023 at 07:52:32PM +0200, Dragan Simic wrote: >> >> Speaking in general, I somehow find "20220712" a bit more readable >> than >> "2022-07-12" as part of a filename, but that's of course just my >> personal >> preference. > > It's funny how we all have our own preferences for this kind of thing. > Mine happens to be separating the date part from the rest of the > filename with an underscore, but using a hyphen to separate individual > date components like: > > filename_2022-07-12.ext Yes, it's quite funny. I gave it some thought, and I think that my preference is a result of dealing with many PDF files containing schematics, for which some kind of a defacto standard is the "-20220712" naming convention.
Jacob Stopak <jacob@initialcommit.io> writes: > 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... People use "calendar" days usually in order to to differenciate it with "business" days. It may take your package to come cross country and take 5 business days, but if you ship it out on Friday, it will not arrive by Wednesday.
diff --git a/builtin/bugreport.c b/builtin/bugreport.c index d2ae5c305d..b556c6e135 100644 --- a/builtin/bugreport.c +++ b/builtin/bugreport.c @@ -106,7 +106,7 @@ int cmd_bugreport(int argc, const char **argv, const char *prefix) struct tm tm; enum diagnose_mode diagnose = DIAGNOSE_NONE; char *option_output = NULL; - char *option_suffix = "%Y-%m-%d-%H%M"; + char *option_suffix = "%Y-%m-%d-%H%M%S"; const char *user_relative_path = NULL; char *prefixed_filename; size_t output_path_len;
Currently, git bugreport postfixes the default bugreport filename (and diagnostics zip filename if --diagnose is supplied) with the current calendar hour and minute values, assuming the -s flag is absent. If a user runs the bugreport command more than once within a calendar minute, a filename conflict with an existing file occurs and the program errors, since the new output filename was already used for the previous file. If the user waits anywhere from 1 to 60 seconds (depending on _when_ during the calendar minute the first command was run) the command works again with no error since the default filename is now unique, and multiple bug reports are able to be created with default settings. This is a minor thing but can cause confusion especially for first time users of the bugreport command, who are likely to run it multiple times in quick succession to learn how it works, (like I did). This patch adds the calendar second value to the default bugreport filename. This technically just shortens the window during which the issue occurs, but a single second is a small enough time increment that users will avoid the filename conflict in practice in this scenario. This means the user will end up with multiple bugreport files being created if they run the command multiple times quickly, but that feels more intuitive and consistent than an error arbitrarily occuring within a calendar minute, especially given that the time window in which the error currently occurs is variable as described above. Signed-off-by: Jacob Stopak <jacob@initialcommit.io> --- builtin/bugreport.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) base-commit: 493f4622739e9b64f24b465b21aa85870dd9dc09