git/usage.c, branch gitk-resize-error

config API: use get_error_routine(), not vreportf()

2021-12-07T21:25:16Z

Change the git_die_config() function added in 5a80e97c827 (config: add `git_die_config()` to the config-set API, 2014-08-07) to use the public callbacks in the usage.[ch] API instead of the the underlying vreportf() function. In preceding commits the rest of the vreportf() users outside of usage.c was migrated to die_message(), so we can now make it "static". Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

usage.c + gc: add and use a die_message_errno()

2021-12-07T21:25:16Z

Change the "error: " output when we exit with 128 due to gc.log errors to use a "fatal: " prefix instead. To do this add a die_message_errno() a sibling function to the die_errno() added in a preceding commit. Before this we'd expect report_last_gc_error() to return -1 from error_errno() in this case. It already treated a status of 0 and 1 specially. Let's just document that anything that's not 0 or 1 should be returned. We could also retain the "ret < 0" behavior here without hardcoding 128 by returning -128, and having the caller do a "return -ret", but I think this makes more sense, and preserves the path from die_message*()'s return value to the "return" without hardcoding "128". Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

usage.c: add a die_message() routine

2021-12-07T21:25:15Z

We have code in various places that would like to call die(), but wants to defer the exit(128) it would invoke, e.g. to print an additional message, or adjust the exit code. Add a die_message() helper routine to bridge this gap in the API. Functionally this behaves just like the error() routine, except it'll print a "fatal: " prefix, and it will return with 128 instead of -1, this is so that caller can pass the return value to "exit()", instead of having to hardcode "exit(128)". Note that as with the other routines the "die_message_builtin" needs to return "void" and otherwise conform to the "report_fn" signature. As we'll see in a subsequent commit callers will want to replace e.g. their default "die_routine" with a "die_message_routine". For now we're just adding the routine and making die_builtin() in usage.c itself use it. In order to do that we need to add a get_die_message_routine() function, which works like the other get_*_routine() functions in usage.c. There is no set_die_message_rotine(), as it hasn't been needed yet. We can add it if we ever need it. Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

usage.c: don't copy/paste the same comment three times

2021-04-13T21:56:28Z

In ee4512ed481 (trace2: create new combined trace facility, 2019-02-22) we started with two copies of this comment, 0ee10fd1296 (usage: add trace2 entry upon warning(), 2020-11-23) added a third. Let's instead add an earlier comment that applies to all these mostly-the-same functions. Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

usage: trace2 BUG() invocations

2021-02-09T22:14:34Z

die() messages are traced in trace2, but BUG() messages are not. Anyone tracking die() messages would have even more reason to track BUG(). Therefore, write to trace2 when BUG() is invoked. Signed-off-by: Jonathan Tan Helped-by: Jeff King Signed-off-by: Junio C Hamano

Merge branch 'jt/trace-error-on-warning'

2020-12-08T23:11:17Z

Like die() and error(), a call to warning() will also trigger a trace2 event. * jt/trace-error-on-warning: usage: add trace2 entry upon warning()

usage: add trace2 entry upon warning()

2020-11-25T01:39:38Z

Emit a trace2 error event whenever warning() is called, just like when die(), error(), or usage() is called. This helps debugging issues that would trigger warnings but not errors. In particular, this might have helped debugging an issue I encountered with commit graphs at $DAYJOB [1]. There is a tradeoff between including potentially relevant messages and cluttering up the trace output produced. I think that warning() messages should be included in traces, because by its nature, Git is used over multiple invocations of the Git tool, and a failure (currently traced) in a Git invocation might be caused by an unexpected interaction in a previous Git invocation that only has a warning (currently untraced) as a symptom - as is the case in [1]. [1] https://lore.kernel.org/git/20200629220744.1054093-1-jonathantanmy@google.com/ Signed-off-by: Jonathan Tan Signed-off-by: Junio C Hamano

usage: define a type for a reporting function

2020-10-16T15:33:58Z

The usage, die, warning, and error routines all work with a function pointer that takes the message to be reported. We usually just mention the function's full type inline. But this makes the use of these pointers hard to read, especially because C's syntax for returning a function pointer is so awful: void (*get_error_routine(void))(const char *err, va_list params); Unless you read it very carefully, this looks like a function pointer declaration. Let's instead use a single typedef to define a reporting function, which is the same for all four types. Note that this also removes the "extern" from these declarations to match the surrounding functions. They were missed in 554544276a (*.[ch]: remove extern from function declarations using spatch, 2019-04-29) presumably because of the unusual syntax. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

vreportf(): avoid relying on stdio buffering

2019-11-02T06:20:21Z

The MSVC runtime behavior differs from glibc's with respect to `fprintf(stderr, ...)` in that the former writes out the message character by character. In t5516, this leads to a funny problem where a `git fetch` process as well as the `git upload-pack` process spawned by it _both_ call `die()` at the same time. The output can look like this: fatal: git uploadfata-lp: raemcokte :error: upload-pnot our arcef k6: n4ot our ea4cr1e3f 36d45ea94fca1398e86a771eda009872d63adb28598f6a9 8e86a771eda009872d6ab2886 Let's avoid this predicament altogether by rendering the entire message, including the prefix and the trailing newline, into the buffer we already have (and which is still fixed size) and then write it out via `write_in_full()`. We still clip the message to at most 4095 characters. The history of `vreportf()` with regard to this issue includes the following commits: d048a96e (2007-11-09) - 'char msg[256]' is introduced to avoid interleaving 389d1767 (2009-03-25) - Buffer size increased to 1024 to avoid truncation 625a860c (2009-11-22) - Buffer size increased to 4096 to avoid truncation f4c3edc0 (2015-08-11) - Buffer removed to avoid truncation b5a9e435 (2017-01-11) - Reverts f4c3edc0 to be able to replace control chars before sending to stderr 9ac13ec9 (2006-10-11) - Another attempt to solve interleaving. This is seemingly related to d048a96e. 137a0d0e (2007-11-19) - Addresses out-of-order for display() 34df8aba (2009-03-10) - Switches xwrite() to fprintf() in recv_sideband() to support UTF-8 emulation eac14f89 (2012-01-14) - Removes the need for fprintf() for UTF-8 emulation, so it's safe to use xwrite() again 5e5be9e2 (2016-06-28) - recv_sideband() uses xwrite() again Note that we print nothing if the `vsnprintf()` call failed to render the error message; There is little we can do in that case, and it should not happen anyway. The process may have written to `stderr` and there may be something left in the buffer kept in the stdio layer. Call `fflush(stderr)` before writing the message we prepare in this function. Helped-by: Jeff King Helped-by: Alexandr Miloslavskiy Helped-by: SZEDER Gábor Helped-by: Junio C Hamano Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

trace2: create new combined trace facility

2019-02-22T23:27:59Z

Create a new unified tracing facility for git. The eventual intent is to replace the current trace_printf* and trace_performance* routines with a unified set of git_trace2* routines. In addition to the usual printf-style API, trace2 provides higer-level event verbs with fixed-fields allowing structured data to be written. This makes post-processing and analysis easier for external tools. Trace2 defines 3 output targets. These are set using the environment variables "GIT_TR2", "GIT_TR2_PERF", and "GIT_TR2_EVENT". These may be set to "1" or to an absolute pathname (just like the current GIT_TRACE). * GIT_TR2 is intended to be a replacement for GIT_TRACE and logs command summary data. * GIT_TR2_PERF is intended as a replacement for GIT_TRACE_PERFORMANCE. It extends the output with columns for the command process, thread, repo, absolute and relative elapsed times. It reports events for child process start/stop, thread start/stop, and per-thread function nesting. * GIT_TR2_EVENT is a new structured format. It writes event data as a series of JSON records. Calls to trace2 functions log to any of the 3 output targets enabled without the need to call different trace_printf* or trace_performance* routines. Signed-off-by: Jeff Hostetler Signed-off-by: Junio C Hamano