git log --oneline | head -n 2
This is a common problem with "head" in a pipeline: "head" exits too early, the pipe is automatically closed, and "git log" gets a SIGPIPE when trying to write to the closed pipe. Many tools do not ignore SIGPIPE (why should they?), and they get killed as a result. Here you have more details about this issue: https://lists.gnu.org/archive/html/coreutils/2019-10/msg00032.html Without "pipefail", you just weren't realising that "git log" was failing (or getting killed). In this case, it does not really matter, as you just want the first 2 text lines. The trouble is, without pipefail you wouldn't realise of any other possible problem with "git log", or whatever command is to the left of the pipe, like here: false | head -n 2 Ignoring errors is always bad practice, especially in a long shell script or a complex operation, where you cannot really inspect all stderr output in order to realise that something went wrong. Your example is fine because it is intended for interactive usage, so you will hopefully see any eventual error message in the console. The pipe buffer size may help in your example: if it is very big, "git log" may write all its output to the buffer and exit before "head" has had time to close the pipe. Such code is always racy: depending on the pipe buffer size, the CPU scheduler, and perhaps even the current system load, you may get an error exit code, or not. The issue in your command is what to do with "head". The fastest and cleanest implementation would be stop generating so many log lines if you only want the first 2. But I do not know whether "git log" can do that. Failing that, you could make sure you always consume everything that "git log" generates, like this: set -o pipefail && ( echo "a" && sleep 1 && echo "b" ) | ( head -n 1 && cat > /dev/null ) Alternatively, you could capture the "git log" exit code and specifically check for SIGPIPE. Depending on how you get the exit code, you may need to look for 128 + 13 (SIGPIPE) = 141. The question is whether you can safely say that SIGPIPE is always fine. I guess in this situation you can, as you would expect "head" to be properly written and never close stdin upon error but nevertheless return a zero exit code. But generally, such assumptions may turn to be wrong, or may help cover bugs in other tools. Regards, rdiez
