git/pager.c, branch jch

pager: explicitly cast away strchr() constness

2026-04-02T05:08:51Z

When we do: char *cp = strchr(argv[i], '='); it implicitly removes the constness from argv[i]. We need "cp" to remain writable (since we overwrite it with a NUL). In theory we should be able to drop the const from argv[i], because it is a sub-pointer into our duplicated pager_env variable. But we get it from split_cmdline(), which uses the traditional "const char **" type for argv. This is overly limiting, but changing it would be awkward for all the other callers of split_cmdline(). Let's do an explicit cast with a note about why it is OK. This is enough to silence compiler warnings about the implicit const problems. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

pager: stop using `the_repository`

2024-12-18T18:44:30Z

Stop using `the_repository` in the "pager" subsystem by passing in a repository when setting up the pager and when configuring it. Adjust callers accordingly by using `the_repository`. While there may be some callers that have a repository available in their context, this trivial conversion allows for easier verification and bubbles up the use of `the_repository` by one level. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

config: make dependency on repo in `read_early_config()` explicit

2024-09-12T17:15:40Z

The `read_early_config()` function can be used to read configuration where a repository has not yet been set up. As such, it is optional whether or not `the_repository` has already been initialized. If it was initialized we use its commondir and gitdir. If not, the function will try to detect the Git directories by itself and, if found, also parse their config files. This means that we implicitly rely on `the_repository`. Make this dependency explicit by passing a `struct repository`. This allows us to again drop the `USE_THE_REPOSITORY_VARIABLE` define in "config.c". Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

rebase --exec: respect --quiet

2024-08-21T15:57:51Z

rebase --exec doesn't obey --quiet and ends up printing messages about the command being executed: git rebase HEAD~3 --quiet --exec true Executing: true Executing: true Executing: true Let's fix that by omitting the "Executing" messages when using --quiet. Furthermore, the sequencer code includes a few calls to term_clear_line(), which prints a special character sequence to erase the previous line displayed on stderr (even when nothing was printed yet). For an user running the command interactively, the net effect of calling this function with or without --quiet is the same as the characters are invisible in the terminal. However, when redirecting the output to a file or piping to another command, the presence of these invisible characters is noticeable, and it may break user expectation as --quiet is not being respected. We could skip the term_clear_line() calls when --quiet is used, like we are doing with the "Executing" messages, but it makes much more sense to condition the line cleaning upon stderr being TTY, since these characters are really only useful for TTY outputs. The added test checks for both these two changes. Reported-by: Lincoln Yuji Reported-by: Rodrigo Siqueira Signed-off-by: Matheus Tavares Signed-off-by: Junio C Hamano

pager: introduce wait_for_pager

2024-07-25T16:03:00Z

Since f67b45f862 (Introduce trivial new pager.c helper infrastructure, 2006-02-28) we have the machinery to send our output to a pager. That machinery, once set up, does not allow us to regain the original stdio streams. In the interactive commands (i.e.: add -p) we want to use the pager for some output, while maintaining the interaction with the user. Modify the pager machinery so that we can use `setup_pager()` and, once we've finished sending the desired output for the pager, wait for the pager termination using a new function `wait_for_pager()`. Make this function reset the pager machinery before returning. One specific point to note is that we avoid forking the pager in `setup_pager()` if the configured pager is an empty string [*1*] or simply "cat" [*2*]. In these cases, `setup_pager()` does nothing and therefore `wait_for_pager()` should not be called. We could modify `setup_pager()` to return an indication of these situations, so we could avoid calling `wait_for_pager()`. However, let's avoid transferring that responsibility to the caller and instead treat the call to `wait_for_pager()` as a no-op when we know we haven't forked the pager. 1.- 402461aab1 (pager: do not fork a pager if PAGER is set to empty., 2006-04-16) 2.- caef71a535 (Do not fork PAGER=cat, 2006-04-16) Signed-off-by: Rubén Justo Signed-off-by: Junio C Hamano

pager: do not close fd 2 unnecessarily

2024-07-25T16:03:00Z

We send errors to the pager since 61b80509e3 (sending errors to stdout under $PAGER, 2008-02-16). In a8335024c2 (pager: do not dup2 stderr if it is already redirected, 2008-12-15) an exception was introduced to avoid redirecting stderr if it is not connected to a terminal. In such exceptional cases, the close(STDERR_FILENO) we're doing in close_pager_fds, is unnecessary. Furthermore, in a subsequent commit we're going to introduce changes that will involve using close_pager_fds multiple times. With this in mind, controlling when we want to close stderr, become sensible. Let's close(STDERR_FILENO) only when necessary, and pave the way for the upcoming changes. Signed-off-by: Rubén Justo Signed-off-by: Junio C Hamano

Merge branch 'rj/pager-die-upon-exec-failure'

2024-07-08T21:53:08Z

When GIT_PAGER failed to spawn, depending on the code path taken, we failed immediately (correct) or just spew the payload to the standard output (incorrect). The code now always fail immediately when GIT_PAGER fails. * rj/pager-die-upon-exec-failure: pager: die when paging to non-existing command

pager: die when paging to non-existing command

2024-06-25T20:47:13Z

When trying to execute a non-existent program from GIT_PAGER, we display an error. However, we also send the complete text to the terminal and return a successful exit code. This can be confusing for the user and the displayed error could easily become obscured by a lengthy text. For example, here the error message would be very far above after sending 50 MB of text: $ GIT_PAGER=non-existent t/test-terminal.perl git log | wc -c error: cannot run non-existent: No such file or directory 50314363 Let's make the error clear by aborting the process and return an error so that the user can easily correct their mistake. This will be the result of the change: $ GIT_PAGER=non-existent t/test-terminal.perl git log | wc -c error: cannot run non-existent: No such file or directory fatal: unable to execute pager 'non-existent' 0 The behavior change we're introducing in this commit affects two tests in t7006, which is a good sign regarding test coverage and requires us to address it. The first test is 'git skips paging non-existing command'. This test comes from f7991f01f2 (t7006: clean up SIGPIPE handling in trace2 tests, 2021-11-21,) where a modification was made to a test that was originally introduced in c24b7f6736 (pager: test for exit code with and without SIGPIPE, 2021-02-02). That original test was, IMHO, in the same direction we're going in this commit. At any rate, this test obviously needs to be adjusted to check the new behavior we are introducing. Do it. The second test being affected is: 'non-existent pager doesnt cause crash', introduced in f917f57f40 (pager: fix crash when pager program doesn't exist, 2021-11-24). As its name states, it has the intention of checking that we don't introduce a regression that produces a crash when GIT_PAGER points to a nonexistent program. This test could be considered redundant nowadays, due to us already having several tests checking implicitly what a non-existent command in GIT_PAGER produces. However, let's maintain a good belt-and-suspenders strategy; adapt it to the new world. Finally, it's worth noting that we are not changing the behavior if the command specified in GIT_PAGER is a shell command. In such cases, it is: $ GIT_PAGER=:\;non-existent t/test-terminal.perl git log :;non-existent: 1: non-existent: not found died of signal 13 at t/test-terminal.perl line 33. Signed-off-by: Rubén Justo Signed-off-by: Junio C Hamano

config: clarify memory ownership in `git_config_string()`

2024-05-27T18:20:00Z

The out parameter of `git_config_string()` is a `const char **` even though we transfer ownership of memory to the caller. This is quite misleading and has led to many memory leaks all over the place. Adapt the parameter to instead be `char **`. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

config: add ctx arg to config_fn_t

2023-06-28T21:06:39Z

Add a new "const struct config_context *ctx" arg to config_fn_t to hold additional information about the config iteration operation. config_context has a "struct key_value_info kvi" member that holds metadata about the config source being read (e.g. what kind of config source it is, the filename, etc). In this series, we're only interested in .kvi, so we could have just used "struct key_value_info" as an arg, but config_context makes it possible to add/adjust members in the future without changing the config_fn_t signature. We could also consider other ways of organizing the args (e.g. moving the config name and value into config_context or key_value_info), but in my experiments, the incremental benefit doesn't justify the added complexity (e.g. a config_fn_t will sometimes invoke another config_fn_t but with a different config value). In subsequent commits, the .kvi member will replace the global "struct config_reader" in config.c, making config iteration a global-free operation. It requires much more work for the machinery to provide meaningful values of .kvi, so for now, merely change the signature and call sites, pass NULL as a placeholder value, and don't rely on the arg in any meaningful way. Most of the changes are performed by contrib/coccinelle/config_fn_ctx.pending.cocci, which, for every config_fn_t: - Modifies the signature to accept "const struct config_context *ctx" - Passes "ctx" to any inner config_fn_t, if needed - Adds UNUSED attributes to "ctx", if needed Most config_fn_t instances are easily identified by seeing if they are called by the various config functions. Most of the remaining ones are manually named in the .cocci patch. Manual cleanups are still needed, but the majority of it is trivial; it's either adjusting config_fn_t that the .cocci patch didn't catch, or adding forward declarations of "struct config_context ctx" to make the signatures make sense. The non-trivial changes are in cases where we are invoking a config_fn_t outside of config machinery, and we now need to decide what value of "ctx" to pass. These cases are: - trace2/tr2_cfg.c:tr2_cfg_set_fl() This is indirectly called by git_config_set() so that the trace2 machinery can notice the new config values and update its settings using the tr2 config parsing function, i.e. tr2_cfg_cb(). - builtin/checkout.c:checkout_main() This calls git_xmerge_config() as a shorthand for parsing a CLI arg. This might be worth refactoring away in the future, since git_xmerge_config() can call git_default_config(), which can do much more than just parsing. Handle them by creating a KVI_INIT macro that initializes "struct key_value_info" to a reasonable default, and use that to construct the "ctx" arg. Signed-off-by: Glen Choo Signed-off-by: Junio C Hamano