Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
pager_in_use: make sure output is still going to pager
When we start a pager, we set GIT_PAGER_IN_USE=1 in the environment. This lets sub-processes know that even though isatty(1) is not true, it is because it is connected to a pager (and we should still turn on human-readable niceties like auto-color). Unfortunately, this is too inclusive for scripts which invoke git sub-programs with their stdout going somewhere else. For example, if you run "git -p pull rebase", git-pull will invoke "git rebase", which invokes: git format-patch ... >rebased-patches This format-patch process knows that its stdout is not a tty, but because of GIT_PAGER_IN_USE it assumes this is because stdout is going to a pager. As a result, it writes colorized output, and the matching "git am" invocation chokes on it, causing the rebase to fail. We could work around this by passing "--no-color" to format-patch, or by removing GIT_PAGER_IN_USE from the environment. But we should not have to do so; format-patch should be able to realize that even though GIT_PAGER_IN_USE is set, its stdout is not actually going to that pager. For this simple case, format-patch could see that its output is not even a pipe. But that would not catch a case like: git format-patch | some-program >rebased-patches where it cannot distinguish between the pipe to the pager and the pipe to some-program. This patch solves it by actually noting the inode of the pipe to the pager in the environment, which readers of GIT_PAGER_IN_USE can check against their stdout. This technically makes GIT_PAGER_IN_USE redundant (we can just check the new GIT_PAGER_PIPE_ID), but we keep using both variables for compatibility with external scripts: - scripts which check GIT_PAGER_IN_USE can continue to do so, and will just ignore the new pipe-id variable. Meaning they may accidentally turn on colors if their output is redirected to a file, but that is the same as today and we cannot fix that. We do not actively break them from showing colors when their stdout _does_ go to the pager. - scripts which set GIT_PAGER_IN_USE but not GIT_PAGER_PIPE_ID will continue to turn on colorization for git sub-commands (again, they do not benefit from the new code, but we are not making anything worse). The inode-retrieval code itself is abstracted into compat/, as different platforms may represent the pipe id differently. These ids do not need to be portable across systems, only within processes on the same system. Note that there is an existing test in t7006 which tests for the exact _opposite_ of what we are trying to achieve (namely, that GIT_PAGER_IN_USE does _not_ cause us to write colors to a random file). This test comes from a battery of tests added by 60b6e22 (tests: Add tests for automatic use of pager, 2010-02-19), and I think is simply misguided, as evidenced by the real "git pull" bug above. If you want to ensure colors in a file, you do it with "--color", not by pretending you have a pager. Rather than delete the test, though, we simply re-title it here. It actually makes a good check of the "scripts which set PAGER_IN_USE but not PAGER_PIPE_ID" historical compatibility mentioned above. Signed-off-by: Jeff King <[email protected]>
- Loading branch information