On Tue, Aug 6, 2024 at 1:11 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > Junio C Hamano <gitster@xxxxxxxxx> writes: > > Patrick Steinhardt <ps@xxxxxx> writes: > >> I always have to wonder how helpful it really is to print the usage > >> information in such a context. I feel that it is too distracting because > >> in many cases, we end up printing dozens of lines of options that drown > >> out the single line of information that the user actually cares for, > >> namely why the command has failed. Thank you, Patrick, for voicing this concern; I nearly did so myself upon reading this series. I always find it very user-hostile when the program dumps the entire usage text, thus forcing the user to sift through a bunch of noise, when it should instead just be printing a simple explanation of the problem to help the user correct the invocation. (It's even more frustrating when a program dumps the usage text but doesn't even bother explaining the problem[*], as if the user will somehow be able to intuit what went wrong.) [*]: https://lore.kernel.org/git/CAPig+cSK+wLPUDuGf1d41J_F5jQS+J=a=7kHQLV07-ZKZW9GsA@xxxxxxxxxxxxxx/ > Yes. I do not think I found it useful to give the single-line > message, blank line, followed by the full usage text even a single > time myself. > > I am very much tempted to suggest us do this. > > void NORETURN usage_msg_opt(const char *msg, > - const char * const *usagestr, > - const struct option *options) > + const char * const *usagestr UNUSED, > + const struct option *options UNUSED) > { > - die_message("%s\n", msg); /* The extra \n is intentional */ > - usage_with_options(usagestr, options); > + die("%s", msg); > } As a minimal "fix" to eliminate the user-hostile behavior, I would be very much in favor of this change. (Retiring `usage_msg_opt` altogether would be even better, but is much more invasive.)
