summaryrefslogtreecommitdiff
path: root/Documentation/technical/api-lockfile.txt
diff options
context:
space:
mode:
authorLibravatar Jeff King <peff@peff.net>2009-01-22 01:03:28 -0500
committerLibravatar Junio C Hamano <gitster@pobox.com>2009-01-21 22:46:53 -0800
commita3da8821208d6243dc5530d668f7c8f089814899 (patch)
treea0ba9685d325f80b8ef826a29114d5940b2186bf /Documentation/technical/api-lockfile.txt
parentrefactor signal handling for cleanup functions (diff)
downloadtgif-a3da8821208d6243dc5530d668f7c8f089814899.tar.xz
pager: do wait_for_pager on signal death
Since ea27a18 (spawn pager via run_command interface), the original git process actually does git work, and the pager is a child process (actually, on Windows it has always been that way, since Windows lacks fork). After spawning the pager, we register an atexit() handler that waits for the pager to finish. Unfortunately, that handler does not always run. In particular, if git is killed by a signal, then we exit immediately. The calling shell then thinks that git is done; however, the pager is still trying to run and impact the terminal. The result can be seen by running a long git process with a pager (e.g., "git log -p") and hitting ^C. Depending on your config, you should see the shell prompt, but pressing a key causes the pager to do any terminal de-initialization sequence. This patch just intercepts any death-dealing signals and waits for the pager before dying. Under typical less configuration, that means hitting ^C will cause git to stop generating output, but the pager will keep running. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'Documentation/technical/api-lockfile.txt')
0 files changed, 0 insertions, 0 deletions