On Tue, Jun 8, 2010 at 3:59 PM, Johannes Sixt <j.sixt@xxxxxxxxxxxxx> wrote: > Your repository has only 2 commits and its git log output is less than 1kB, > i.e., sufficiently small to fit in a pipe's buffer. > > git log calls start_command to fork() the pager. The OS's scheduler does not > run the newly forked process immediately; rather, git log goes on with its > own business, writing output to the pipe that connects to the pager. Because > your repository is so small, git log never has to wait that the pager drains > the pipe. git log finally reaches exit(0). At this time, an atexit() handler > (wait_for_pager()) finally calls finish_command() to wait for the pager. > > This is the first time that the forked child process can run. Only now it > turns out that the pager cannot be run. The child process closes the pipe > and exits with an error, but it is too late: wait_for_pager() drops the > error return code of finish_command() to the floor. The parent process (git > log) can complete with the exit code that it was given earlier, 0. > > Repeat your experiment with ./git log in git.git itself to see the > difference. > > -- Hannes > Capisco & touché, with much more than 1k of info, git show ends with a "Broken Pipe"... seems hard to detect for little, recently started projects since I added more than 60k of scripts and I need to do 'git show' to understand that the problem is a broken pipe. Now, let me think about it... do we need the pager_preexec function? I mean... it works fine without it, and the function is there because of a faulty 'less'. My problem is obvioulsly solved by adding PAGER=more in my default environment, but I think this could be a litle bit embarrassing for a new user, mostly in environments such this AIX :P Cheers, Dario -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html