I have some understanding of how the stdout and stderr file descriptors work. But sometimes they don’t catch all the output and I trying to understand why. For example, cloning into a git repo gives the following output:

$ git clone [email protected]:Alex23rodriguez/MyRepo
Cloning into 'MyRepo'...
remote: Enumerating objects: 438, done.
remote: Counting objects: 100% (438/438), done.
remote: Compressing objects: 100% (319/319), done.
remote: Total 438 (delta 96), reused 410 (delta 68), pack-reused 0
Receiving objects: 100% (438/438), 13.09 MiB | 1.73 MiB/s, done.
Resolving deltas: 100% (96/96), done.

but redirecting both stdout and stderr to a file gives unexpected results

$ git clone [email protected]:Alex23rodriguez/MyRepo &> log
(no output)
$ cat log
Cloning into 'MyRepo'...

My question is, what happened to the rest of the printed lines?

  • From here: You should use git clone --progress to be able to get the full output. Also it seems you can use unbuffer git clone https://.... Dec 22, 2022 at 22:06

1 Answer 1


They were simply never printed: git probably simply checks whether the stdout and stderr file descriptors are ttys, and if not, it omits the pretty print verbose status updates.

  • thanks! I didn't know programs could check if they were being piped. My question wasn't specifically about git clone but now it makes sense.
    – alex23ro
    Dec 22, 2022 at 22:45
  • 1
    @alex23ro Even ls uses this trick, in respect of number of columns, and of colourising. Try ls versus ls | cat. Dec 23, 2022 at 9:26
  • Hey @ilkkachu! Thanks for the (saving me) edit :) I'll going to revert one single word, for pedantism reasons, hope you'll not be sad :) Dec 23, 2022 at 9:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .