git/trace.c, branch v2.16.2

trace: improve performance while category is disabled

2017-12-06T17:43:02Z

Move just enough code from trace.c into trace.h header so all code necessary to determine that trace is disabled could be inlined to calling functions. Then perform the check if the trace key is enabled sooner in call chain. Signed-off-by: Gennady Kupava Signed-off-by: Junio C Hamano

trace: remove trace key normalization

2017-11-27T01:19:08Z

Trace key normalization is not used, not strictly necessary, complicates the code and would negatively affect compilation speed if moved to header. New trace_default_key key or existing separate marco could be used instead of passing NULL as a key. Signed-off-by: Gennady Kupava Signed-off-by: Junio C Hamano

Replace Free Software Foundation address in license notices

2017-11-09T04:21:21Z

The mailing address for the FSF has changed over the years. Rather than updating the address across all files, refer readers to gnu.org, as the GNU GPL documentation now suggests for license notices. The mailing address is retained in the full license files (COPYING and LGPL-2.1). The old address is still present in t/diff-lib/COPYING. This is intentional, as the file is used in tests and the contents are not expected to change. Signed-off-by: Todd Zullinger Signed-off-by: Junio C Hamano

trace: do not fall back to stderr

2016-08-05T16:28:17Z

If the trace code cannot open a specified file, or does not understand the contents of the GIT_TRACE variable, it falls back to printing trace output to stderr. This is an attempt to be helpful, but in practice it just ends up annoying. The user was trying to get the output to go somewhere else, so spewing it to stderr does not really accomplish that. And as it's intended for debugging, they can presumably re-run the command with their error corrected. So instead of falling back, this patch disables bogus trace keys for the rest of the program, just as we do for write errors. We can drop the "Defaulting to..." part of the error message entirely; after seeing "cannot open '/foo'", the user can assume that tracing is skipped. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

trace: disable key after write error

2016-08-05T16:28:16Z

If we get a write error writing to a trace descriptor, the error isn't likely to go away if we keep writing. Instead, you'll just get the same error over and over. E.g., try: GIT_TRACE_PACKET=42 git ls-remote >/dev/null You don't really need to see: warning: unable to write trace for GIT_TRACE_PACKET: Bad file descriptor hundreds of times. We could fallback to tracing to stderr, as we do in the error code-path for open(), but there's not much point. If the user fed us a bogus descriptor, they're probably better off fixing their invocation. And if they didn't, and we saw a transient error (e.g., ENOSPC writing to a file), it probably doesn't help anybody to have half of the trace in a file, and half on stderr. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

trace: correct variable name in write() error message

2016-08-05T16:28:16Z

Our error message for write() always mentions GIT_TRACE, even though we may be writing for a different variable entirely. It's also not quite accurate to say "fd given by GIT_TRACE environment variable", as we may hit this error based on a filename the user put in the variable (we do complain and switch to stderr if the file cannot be opened, but it's still possible to hit a write() error on the descriptor later). So let's fix those things, and switch to our more usual "unable to do X: Y" format for the error. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

trace: cosmetic fixes for error messages

2016-08-05T16:28:16Z

The error messages for the trace code are often multi-line; the first line gets a nice "warning:", but the rest are left-aligned. Let's give them an indentation to make sure they stand out as a unit. While we're here, let's also downcase the first letter of each error (our usual style), and break up a long line of advice (since we're already using multiple lines, one more doesn't hurt). We also replace "What does 'foo' for GIT_TRACE mean?". While cute, it's probably a good idea to give more context, and follow our usual styles. So it's now "unknown trace value for 'GIT_TRACE': foo". Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

trace: use warning() for printing trace errors

2016-08-05T16:27:34Z

Right now we just fprintf() straight to stderr, which can make the output hard to distinguish. It would be helpful to give it one of our usual prefixes like "error:", "warning:", etc. It doesn't make sense to use error() here, as the trace code is "optional" debugging code. If something goes wrong, we should warn the user, but saying "error" implies the actual git operation had a problem. So warning() is the only sane choice. Note that this does end up calling warn_routine() to do the formatting. This is probably a good thing, since they are clearly trying to hook messages before they make it to stderr. However, it also means that in theory somebody who tries to trace from their warn_routine() could cause a loop. This seems rather unlikely in practice (we've never even overridden the default warn_builtin routine before, and recent discussions to do so would just install a noop routine). Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

trace: stop using write_or_whine_pipe()

2016-08-04T20:33:27Z

The write_or_whine_pipe function does two things: 1. it checks for EPIPE and converts it into a signal death 2. it prints a message to stderr on error The first thing does not help us, and actively hurts. Generally we would simply die from SIGPIPE in this case, unless somebody has taken the time to ignore SIGPIPE for the whole process. And if they _did_ do that, it seems rather silly for the trace code, which otherwise takes pains to continue even in the face of errors (e.g., by not using write_or_die!), to take down the whole process for one specific type of error. Nor does the second thing help us; it just makes it harder to write our error message, because we have to feed bits of it as an argument to write_or_whine_pipe(). Translators never get to see the full message, and it's hard for us to customize it. Let's switch to just using write_in_full() and writing our own error string. For now, the error is identical to what write_or_whine_pipe() would say, but now that it's more under our control, we can improve it in future patches. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

trace: handle NULL argument in trace_disable()

2016-08-04T20:33:27Z

All of the trace functions treat a NULL key as a synonym for the default GIT_TRACE key. Except for trace_disable(), which will segfault. Fortunately, this can't cause any bugs, as the function has no callers. But rather than drop it, let's fix the bug, as I plan to add a caller. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano