summaryrefslogtreecommitdiffstats
path: root/sub-process.h
diff options
context:
space:
mode:
authorMatheus Tavares <matheus.tavb@gmail.com>2024-08-21 03:31:52 +0200
committerJunio C Hamano <gitster@pobox.com>2024-08-21 17:57:51 +0200
commit4bdd6b7bf22a5e69125fd4ef1faf4e505d3ba583 (patch)
treedb7db4e23a84de833c61ed52beb252603198f0b8 /sub-process.h
parentThe fifth batch (diff)
downloadgit-4bdd6b7bf22a5e69125fd4ef1faf4e505d3ba583.tar.xz
git-4bdd6b7bf22a5e69125fd4ef1faf4e505d3ba583.zip
rebase --exec: respect --quiet
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 <lincolnyuji@hotmail.com> Reported-by: Rodrigo Siqueira <siqueirajordao@riseup.net> Signed-off-by: Matheus Tavares <matheus.tavb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'sub-process.h')
0 files changed, 0 insertions, 0 deletions