git/common-main.c, branch v2.40.3

grep: fix multibyte regex handling under macOS

2022-08-26T18:45:52Z

The commit 29de20504e (Makefile: fix default regex settings on Darwin, 2013-05-11) fixed t0070-fundamental.sh under Darwin (macOS) by adopting Git's regex library. However, this library is compiled with NO_MBSUPPORT, which causes git-grep to work incorrectly on multibyte (e.g. UTF-8) files. Current macOS versions pass t0070-fundamental.sh with the native macOS regex library, which also supports multibyte characters. Adjust the Makefile to use the native regex library, and call setlocale(3) to set CTYPE according to the user's preference. The setlocale call is required on all platforms, but in platforms supporting gettext(3), setlocale was called as a side-effect of initializing gettext. Therefore, move the CTYPE setlocale call from gettext.c to common-main.c and the corresponding locale.h include into git-compat-util.h. Thanks to the global initialization of CTYPE setlocale, the test-tool regex command now works correctly with supported multibyte regexes, and is used to set the MB_REGEX test prerequisite by assessing a platform's support for them. Signed-off-by: Diomidis Spinellis Signed-off-by: Junio C Hamano

usage.c: add a non-fatal bug() function to go with BUG()

2022-06-02T19:51:35Z

Add a bug() function to use in cases where we'd like to indicate a runtime BUG(), but would like to defer the BUG() call because we're possibly accumulating more bug() callers to exhaustively indicate what went wrong. We already have this sort of facility in various parts of the codebase, just in the form of ad-hoc re-inventions of the functionality that this new API provides. E.g. this will be used to replace optbug() in parse-options.c, and the 'error("BUG:[...]' we do in a loop in builtin/receive-pack.c. Unlike the code this replaces we'll log to trace2 with this new bug() function (as with other usage.c functions, including BUG()), we'll also be able to avoid calls to xstrfmt() in some cases, as the bug() function itself accepts variadic sprintf()-like arguments. Any caller to bug() can follow up such calls with BUG_if_bug(), which will BUG() out (i.e. abort()) if there were any preceding calls to bug(), callers can also decide not to call BUG_if_bug() and leave the resulting BUG() invocation until exit() time. There are currently no bug() API users that don't call BUG_if_bug() themselves after a for-loop, but allowing for not calling BUG_if_bug() keeps the API flexible. As the tests and documentation here show we'll catch missing BUG_if_bug() invocations in our exit() wrapper. Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

common-main.c: move non-trace2 exit() behavior out of trace2.c

2022-06-02T19:51:30Z

Change the exit() wrapper added in ee4512ed481 (trace2: create new combined trace facility, 2019-02-22) so that we'll split up the trace2 logging concerns from wanting to wrap the "exit()" function itself for other purposes. This makes more sense structurally, as we won't seem to conflate non-trace2 behavior with the trace2 code. I'd previously added an explanation for this in 368b5843158 (common-main.c: call exit(), don't return, 2021-12-07), that comment is being adjusted here. Now the only thing we'll do if we're not using trace2 is to truncate the "code" argument to the lowest 8 bits. We only need to do that truncation on non-POSIX systems, but in ee4512ed481 that "if defined(__MINGW32__)" code added in 47e3de0e796 (MinGW: truncate exit()'s argument to lowest 8 bits, 2009-07-05) was made to run everywhere. It might be good for clarify to narrow that down by an "ifdef" again, but I'm not certain that in the interim we haven't had some other non-POSIX systems rely the behavior. On a POSIX system taking the lowest 8 bits is implicit, see exit(3)[1] and wait(2)[2]. Let's leave a comment about that instead. 1. https://man7.org/linux/man-pages/man3/exit.3.html 2. https://man7.org/linux/man-pages/man2/wait.2.html Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

Merge branch 'en/keep-cwd'

2022-01-05T22:01:28Z

Many git commands that deal with working tree files try to remove a directory that becomes empty (i.e. "git switch" from a branch that has the directory to another branch that does not would attempt remove all files in the directory and the directory itself). This drops users into an unfamiliar situation if the command was run in a subdirectory that becomes subject to removal due to the command. The commands have been taught to keep an empty directory if it is the directory they were started in to avoid surprising users. * en/keep-cwd: t2501: simplify the tests since we can now assume desired behavior dir: new flag to remove_dir_recurse() to spare the original_cwd dir: avoid incidentally removing the original_cwd in remove_path() stash: do not attempt to remove startup_info->original_cwd rebase: do not attempt to remove startup_info->original_cwd clean: do not attempt to remove startup_info->original_cwd symlinks: do not include startup_info->original_cwd in dir removal unpack-trees: add special cwd handling unpack-trees: refuse to remove startup_info->original_cwd setup: introduce startup_info->original_cwd t2501: add various tests for removing the current working directory

setup: introduce startup_info->original_cwd

2021-12-09T21:33:12Z

Removing the current working directory causes all subsequent git commands run from that directory to get confused and fail with a message about being unable to read the current working directory: $ git status fatal: Unable to read current working directory: No such file or directory Non-git commands likely have similar warnings or even errors, e.g. $ bash -c 'echo hello' shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory hello This confuses end users, particularly since the command they get the error from is not the one that caused the problem; the problem came from the side-effect of some previous command. We would like to avoid removing the current working directory of our parent process; towards this end, introduce a new variable, startup_info->original_cwd, that tracks the current working directory that we inherited from our parent process. For convenience of later comparisons, we prefer that this new variable store a path relative to the toplevel working directory (thus much like 'prefix'), except without the trailing slash. Subsequent commits will make use of this new variable. Acked-by: Derrick Stolee Acked-by: Ævar Arnfjörð Bjarmason Signed-off-by: Elijah Newren Signed-off-by: Junio C Hamano

common-main.c: call exit(), don't return

2021-12-07T20:29:57Z

Change the main() function to call "exit()" instead of ending with a "return" statement. The "exit()" function is our own wrapper that calls trace2_cmd_exit_fl() for us, from git-compat-util.h: #define exit(code) exit(trace2_cmd_exit_fl(__FILE__, __LINE__, (code))) That "exit()" wrapper has been in use ever since ee4512ed481 (trace2: create new combined trace facility, 2019-02-22). This changes nothing about how we "exit()", as we'd invoke "trace2_cmd_exit_fl()" in both cases due to the wrapper, this change makes it easier to reason about this code, as we're now always obviously relying on our "exit()" wrapper. There is already code immediately downstream of our "main()" which has a hard reliance on that, e.g. the various "exit()" calls downstream of "cmd_main()" in "git.c". We even had a comment in "t/helper/test-trace2.c" that seemed to be confused about how the "exit()" wrapper interacted with uses of "return", even though it was introduced in the same trace2 series in a15860dca3f (trace2: t/helper/test-trace2, t0210.sh, t0211.sh, t0212.sh, 2019-02-22), after the aforementioned ee4512ed481. Perhaps it pre-dated the "exit()" wrapper? This change makes the "trace2_cmd_exit()" macro orphaned, we now always use "trace2_cmd_exit_fl()" directly, but let's keep that simpler example in place. Even if we're unlikely to get another "main()" other than the one in our "common-main.c", there's some value in having the API documentation and example discuss a simpler version that doesn't require an "exit()" wrapper macro. Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

common-main: delay trace2 initialization

2019-08-06T20:09:01Z

We initialize the trace2 system in the common main() function so that all programs (even ones that aren't builtins) will enable tracing. But trace2 startup is relatively heavy-weight, as we have to actually read on-disk config to decide whether to trace. This can cause unexpected interactions with other common-main initialization. For instance, we'll end up in the config code before calling initialize_the_repository(), and the usual invariant that the_repository is never NULL will not hold. Let's push the trace2 initialization further down in common-main, to just before we execute cmd_main(). The other parts of the initialization are much more self-contained and less likely to call library code that depends on those kinds of invariants. Originally the trace2 code tried to start as early as possible to get accurate timings. But the timer initialization was split out from the config reading in a089724958 (trace2: refactor setting process starting time, 2019-04-15), so there shouldn't be any impact from this patch. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

trace2: report peak memory usage of the process

2019-04-16T04:37:07Z

Teach Windows version of git to report peak memory usage during exit() processing. Signed-off-by: Jeff Hostetler Signed-off-by: Junio C Hamano

trace2: find exec-dir before trace2 initialization

2019-04-16T04:37:06Z

Teach Git to resolve the executable directory before initializing Trace2. This allows the system configuration directory to be discovered earlier (because it is sometimes relative to the prefix or runtime-prefix). This will be used by the next commit to allow trace2 settings to be loaded from the system config. Signed-off-by: Jeff Hostetler Signed-off-by: Junio C Hamano

trace2: refactor setting process starting time

2019-04-16T04:37:06Z

Create trace2_initialize_clock() and call from main() to capture process start time in isolation and before other sub-systems are ready. Signed-off-by: Jeff Hostetler Signed-off-by: Junio C Hamano