CODEWITHSUNDEEP
gitshellhomebrewzshgnu
Chris
Chris

Reputation: 386

git output is blank, except when captured as in: echo "$(git branch)"

I'm having a strange issue, and I really can't tell whether it's caused by something related to my Git install or my shell, or something else entirely. If I'm in a Git repository with plenty of branches and commits, and I try to list branches:

$ git branch
$ git branch -a
$ git branch --list

There is no output at all. However, if I run the output of these commands through echo the results are as one might expect:

$ echo "`git branch`"
  local-branch-1
  local-branch-2
* master
$ echo "$(git branch -a)"
  local-branch-1
  local-branch-2
* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/master

My configuration is macOS 10.14.6 with Git 2.29.2 installed via Homebrew. I'm using ZSH 5.8 (also Homebrew) with either Prezto or PowerLevel10k configurations. While these tools alias plenty of shortcuts to Git commands, nothing is aliased from git * that could be interfering:

$ type git
git is /usr/local/bin/git
git is /usr/bin/git

I've also tried a virgin Bash 5.0.18 shell, and the results are the same.

ZSH tab completion shows the branches correctly, so if I, for example:

$ git checkout <tab>
local-branch-1   master
local-branch-2   origin/HEAD
HEAD             origin/master

I'm getting similar behavior from some other Git commands, for example git config --local --list. But all of the "action" commands (push, pull, add, commit, etc.) seem to work as intended, including the proper output. (But so do some "info-only" commands, like git version.)

This feels to me like some kind of shell configuration error, but it's only affecting Git as far as I can tell, and it happens in both my fancy ZSH installation and vanilla Bash, so maybe some weird interaction between the two? I've searched high and low for anyone else with a similar problem, but everything I've found boils down to branches not being listed on a fresh repository with no commits, which definitely isn't the case here.

I'm kind of out of ideas at this point, so I'm hoping someone has a suggestion for further investigation.

Upvotes: 2

Views: 583

Answers (1)

Charles Duffy
Charles Duffy

Reputation: 295795

If this only happens when output is to the TTY, it's probably a pager issue.

When running in a regular terminal, unless you capture or redirect git's output with $(git ...) or git ... | otherprogram, isatty(1) is true, so git automatically invokes a pager to let users read content too long to fit on one screen.

If it's a pager issue, there are several options to debug.

  1. See if the problem goes away without a pager.

    • Does git --no-pager branch still have issues?

  2. Check which pager is in use.

    • declare -p GIT_PAGER will show a pager configured only for git via the environment.
    • git config core.pager will show a pager configured only for git via its config files.
    • declare -p PAGER will show a pager configured to be used by your OS in general.

  3. Check how that pager is configured, and try clearing or simplifying that configuration.

    • If your pager is LESS, declare -p LESS will show options configured for it via the environment, and unset LESS will temporarily clear those options.
    • If your pager is MORE, declare -p MORE will show options configured for it via the environment, and unset MORE will temporarily clear those options.
    • For another pager, consider reading its manual.

Regarding this specific instance:

The OP had LESS='-F -g -i -M -R -S -z-4' exported in their environment. The -F argument to less instructs it to exit if there's less than one page of content to be displayed.

On the OP's (MacOS) system, the stock version of less, when called with -F, exited before emitting the original content to stdout; this could be repaired either by removing that flag, or by installing a newer version of less.

Upvotes: 6

Related Questions