32

When I run git branch (from bash or csh), it automagically pipes the output through less. However, with only a few branches in the repository this is beyond unnecessary, it is annoying, as the branch listing disappears once I quit less.

Checking ~/.gitconfig file and the local .git/config files finds nothing about a pager or any thing else that would cause this. Otherwise, nothing I've found in web searches has been helpful or promising.

Why is this happening, and what (if anything) can I do to make less run when needed (e.g. when doing a git log when there's a lot of history) but not otherwise (like a git branch with only 2 or 3 branches)?

Bart
  • 2,151
  • 1
  • 10
  • 26
GreenMatt
  • 695
  • 6
  • 16
  • 4
    In general git doesn't know how much output there is going to be from any command, so it send everything by default through a pager, which will probably be less. – icarus Aug 21 '19 at 23:38
  • 6
    The first thing do on a new -nix installation is to put `export LESS=-X` in the `.profile`. This [keeps less from "cleaning up"](https://linux.die.net/man/1/less) the screen. I *hate* it that the standard setting clears the screen because I often need to cut and paste stuff or use it as a reference. – Peter - Reinstate Monica Aug 22 '19 at 09:25
  • 3
    @Peter To be clear (no pun intended), only people who don't want the screen clearing behavior should do that. – David Z Aug 22 '19 at 10:35
  • @icarus: That seems logical. However, the behavior of mine changed recently. I'm not sure why - probably a change to some environment variable forced from the corporate security folks "on high" who don't seem to care how difficult they make everyone else's jobs. Anyway, git suddenly went from what I considered sensible behavior to running single line outputs through less in such a way that the output was lost when I stopped less. – GreenMatt Aug 22 '19 at 13:20
  • If the behavior recently changed it is at least possible that a setting of the LESS variable was added to the system-wide shell startup files, e.g. /etc/profile, /etc/profile.d/*, /etc/bash.bashrc, Do you have this variable in your environment? – icarus Aug 22 '19 at 15:08

2 Answers2

47

You can set the following:

git config --global core.pager 'less -FRX'

This will ensure that less will

  • Exit if the entire file can be displayed on the first screen (F)
  • Output the raw control characters for terminal formatting (R)
  • Chop long lines (S)
  • Don't send the init/de-init strings to the terminal - avoids clearing the screen on exit (X)

Edit: Removed the S option based on Peter A. Scheider's comment

Kusalananda
  • 320,670
  • 36
  • 633
  • 936
QIS
  • 811
  • 6
  • 16
  • 7
    and omit the `--global` if you want it to only apply to the current repository. –  Aug 21 '19 at 20:06
  • 8
    Setting the environment variable `LESS` to `-FR`, adding in X and S to taste is another way. – icarus Aug 21 '19 at 23:41
  • 2
    See also https://unix.stackexchange.com/questions/469360/less-performs-differently-when-invoked-from-bash-and-from-git?rq=1 – icarus Aug 21 '19 at 23:44
  • 11
    Most likely the OP finds that behavior annoying in general; I suppose one could set the environment variable `export PAGER='less -FRSX'` and git would honor it (absent a specific git config). Btw, `-S` is dangerous because it silently discards output. – Peter - Reinstate Monica Aug 22 '19 at 09:28
5

There are some great answers here for tuning less's behavior, but since my graybeard fingers are accustomed to typing |more when I want it, and since I'm still more in tune with mercurial than with git, I'm keen on

git config --global core.pager cat
dgc
  • 230
  • 1
  • 4
  • 3
    The man page for `git-config` states that the value of `core.pager` is intended to be interpreted by the shell. When you set it to `no`, it tries to execute the command `no`, which most likely doesn't exist, then it falls back to simply outputting the contents. You will still see an error message at the head. What you probably want to do is to set it to `cat` instead. – QIS Aug 22 '19 at 18:57
  • 2
    That's a good piece of information, but what I like is that it doesn't execute _anything_. The `cat` is useless, and I don't particularly trust Linux util maintainers not to change what cat does (cf. [the `ls` quoted files debacle](https://unix.stackexchange.com/questions/258679)). Maybe I should use "don't ever" instead. It's less likely that such a program exists. – dgc Aug 22 '19 at 19:45
  • 7
    Setting `core.pager` to the empty string (`git config core.pager ''`) or to `cat` will __not__ run anything at all. You can work it out yourself if you don't believe me ;-) There's no reason whatsoever to set it to a dummy command like `no`. –  Aug 22 '19 at 21:05
  • Great, thanks! I had no idea the empty string would cause no command execution. As to `cat`, are you saying that git has a special case for that string in the pager code — i.e. that `cat` is effectively a synonym for "null"? I would expect it to execute `cat`. – dgc Aug 27 '19 at 05:47
  • This indeed seems to be the case. Egads. But also good: I'm always looking for more ways to justify my distaste for git. – dgc Aug 27 '19 at 05:56