"git branch" issue in 2.16.1

"git branch" issue in 2.16.1

[Jason Racey]

After upgrading git from 2.16.0 to 2.16.1 (via Homebrew - I’m on macOS) I noticed that the “git branch” command appears to display the branch listing in something similar to a vi editor - though not quite the same. I don’t know the technical term for this state. You can’t actually edit the output of the command, but you’re in a state where you have to type “q” to exit and then the list disappears. It’s very inconvenient and it doesn’t seem like it was by design. I’m using zsh in iTerm2 if that helps. Thanks.

- Jason

Re: "git branch" issue in 2.16.1

[Todd Zullinger]

Hi Jason,

Jason Racey wrote:
> After upgrading git from 2.16.0 to 2.16.1 (via Homebrew -
> I’m on macOS) I noticed that the “git branch” command
> appears to display the branch listing in something similar
> to a vi editor - though not quite the same. I don’t know
> the technical term for this state. You can’t actually edit
> the output of the command, but you’re in a state where you
> have to type “q” to exit and then the list disappears.
> It’s very inconvenient and it doesn’t seem like it was by
> design. I’m using zsh in iTerm2 if that helps. Thanks.

In 2.16.0 `git branch --list` is sent to a pager by default.
(Without arguments, --list is the default, so this applies
to `git branch`).

You can set pager.branch to false to disable this in the
config, or use git --no-pager branch to do so for a single
invocation.

I can't say why you're seeing this with 2.16.1 and not
2.16.0, but I'm not familiar with homebrew, so perhaps
something didn't work as intended in 2.16.0.

-- 
Todd
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Historian, n. A broad-gauge gossip.
    -- Ambrose Bierce, "The Devil's Dictionary"

Re: "git branch" issue in 2.16.1

[Paul Smith]

On Tue, 2018-02-06 at 11:49 -0800, Jason Racey wrote:
> After upgrading git from 2.16.0 to 2.16.1 (via Homebrew - I’m on
> macOS) I noticed that the “git branch” command appears to display the
> branch listing in something similar to a vi editor - though not quite
> the same. I don’t know the technical term for this state. You can’t
> actually edit the output of the command, but you’re in a state where
> you have to type “q” to exit and then the list disappears. It’s very
> inconvenient and it doesn’t seem like it was by design. I’m using zsh
> in iTerm2 if that helps. Thanks.

I think you mean that you're in the pager (less(1), most likely). 
Many/most Git commands that can generate a large amount of output (git
log, git diff, git show, etc.) will automatically send the output to a
pager so you can scroll through it easily.


The man page for git branch says:

  CONFIGURATION
       pager.branch is only respected when listing branches, i.e., when --list
       is used or implied. The default is to use a pager. See git-config(1).

So, if you never want to use the pager for git branch output you can
configure the pager.branch option to set it always off.

Or you can use "git branch | cat" so that stdout is not a terminal :).

Re: "git branch" issue in 2.16.1

[Stefan Beller]

On Tue, Feb 6, 2018 at 11:57 AM, Todd Zullinger <tmz@pobox.com> wrote:
> Hi Jason,
>
> Jason Racey wrote:
>> After upgrading git from 2.16.0 to 2.16.1 (via Homebrew -
>> I’m on macOS) I noticed that the “git branch” command
>> appears to display the branch listing in something similar
>> to a vi editor - though not quite the same. I don’t know
>> the technical term for this state. You can’t actually edit
>> the output of the command, but you’re in a state where you
>> have to type “q” to exit and then the list disappears.
>> It’s very inconvenient and it doesn’t seem like it was by
>> design. I’m using zsh in iTerm2 if that helps. Thanks.
>
> In 2.16.0 `git branch --list` is sent to a pager by default.
> (Without arguments, --list is the default, so this applies
> to `git branch`).
>
> You can set pager.branch to false to disable this in the
> config, or use git --no-pager branch to do so for a single
> invocation.
>
> I can't say why you're seeing this with 2.16.1 and not
> 2.16.0, but I'm not familiar with homebrew, so perhaps
> something didn't work as intended in 2.16.0.
>

Maybe the number of branches changed since then?
As the pager only comes to life when the output fills
more than your screen. Quick workarounds:
* buy a bigger screen
* have fewer branches.

:-)

Stefan

Re: "git branch" issue in 2.16.1

[Lars Schneider]

> On 06 Feb 2018, at 21:05, Stefan Beller <sbeller@google.com> wrote:
> 
> On Tue, Feb 6, 2018 at 11:57 AM, Todd Zullinger <tmz@pobox.com> wrote:
>> Hi Jason,
>> 
>> Jason Racey wrote:
>>> After upgrading git from 2.16.0 to 2.16.1 (via Homebrew -
>>> I’m on macOS) I noticed that the “git branch” command
>>> appears to display the branch listing in something similar
>>> to a vi editor - though not quite the same. I don’t know
>>> the technical term for this state. You can’t actually edit
>>> the output of the command, but you’re in a state where you
>>> have to type “q” to exit and then the list disappears.
>>> It’s very inconvenient and it doesn’t seem like it was by
>>> design. I’m using zsh in iTerm2 if that helps. Thanks.
>> 
>> In 2.16.0 `git branch --list` is sent to a pager by default.
>> (Without arguments, --list is the default, so this applies
>> to `git branch`).
>> 
>> You can set pager.branch to false to disable this in the
>> config, or use git --no-pager branch to do so for a single
>> invocation.
>> 
>> I can't say why you're seeing this with 2.16.1 and not
>> 2.16.0, but I'm not familiar with homebrew, so perhaps
>> something didn't work as intended in 2.16.0.
>> 
> 
> Maybe the number of branches changed since then?
> As the pager only comes to life when the output fills
> more than your screen. Quick workarounds:
> * buy a bigger screen
> * have fewer branches.

Hmmm... there might be more to it. I just noticed the
pager behavior on macOS, too. Consider this call:

$ git diff --shortstat

This should generate at most one line of output. On Linux
the pager is never used. On macOS the pager is always used.

I tried older versions of Git on macOS and experienced the
same behavior.

@Jason: That might be a bug on macOS. However, I am surprised
you only noticed it after upgrading from 2.16.0 to 2.16.1.
Do you recall anything else you've changed?

- Lars

Re: "git branch" issue in 2.16.1

[Jason Racey]

Hi Lars,

Here’s what I’m certain of:

1. Just set up a new MacBook Pro at work. Git version 2.16.1 installed via Homebrew. “git branch” command always displays the list of branches in the less pager, regardless of number of branches or screen size. I’ve never seen this happen before.
2. Checked the “git branch” behavior on my personal MacBook Pro. Git version there is 2.16.0. Does not have this always paging behavior.
3. Ran "brew upgrade git" on personal MacBook Pro. Git upgraded to 2.16.1.
4. Checked the “git branch” behavior on my personal MacBook Pro after version upgrade. Pager now always used regardless of number of branches or screen size. Oh no! Seems like there might be a bug in the new version, better email the git bug list in just to be safe.
5. Meanwhile research problem on Stack Overflow. Mitigated (though not really fixed) issue on both machines with this command: git config --global core.pager ‘’

Thanks!

- Jason


> On Feb 7, 2018, at 9:54 AM, Lars Schneider <larsxschneider@gmail.com> wrote:
> 
> 
>> On 06 Feb 2018, at 21:05, Stefan Beller <sbeller@google.com> wrote:
>> 
>> On Tue, Feb 6, 2018 at 11:57 AM, Todd Zullinger <tmz@pobox.com> wrote:
>>> Hi Jason,
>>> 
>>> Jason Racey wrote:
>>>> After upgrading git from 2.16.0 to 2.16.1 (via Homebrew -
>>>> I’m on macOS) I noticed that the “git branch” command
>>>> appears to display the branch listing in something similar
>>>> to a vi editor - though not quite the same. I don’t know
>>>> the technical term for this state. You can’t actually edit
>>>> the output of the command, but you’re in a state where you
>>>> have to type “q” to exit and then the list disappears.
>>>> It’s very inconvenient and it doesn’t seem like it was by
>>>> design. I’m using zsh in iTerm2 if that helps. Thanks.
>>> 
>>> In 2.16.0 `git branch --list` is sent to a pager by default.
>>> (Without arguments, --list is the default, so this applies
>>> to `git branch`).
>>> 
>>> You can set pager.branch to false to disable this in the
>>> config, or use git --no-pager branch to do so for a single
>>> invocation.
>>> 
>>> I can't say why you're seeing this with 2.16.1 and not
>>> 2.16.0, but I'm not familiar with homebrew, so perhaps
>>> something didn't work as intended in 2.16.0.
>>> 
>> 
>> Maybe the number of branches changed since then?
>> As the pager only comes to life when the output fills
>> more than your screen. Quick workarounds:
>> * buy a bigger screen
>> * have fewer branches.
> 
> Hmmm... there might be more to it. I just noticed the
> pager behavior on macOS, too. Consider this call:
> 
> $ git diff --shortstat
> 
> This should generate at most one line of output. On Linux
> the pager is never used. On macOS the pager is always used.
> 
> I tried older versions of Git on macOS and experienced the
> same behavior.
> 
> @Jason: That might be a bug on macOS. However, I am surprised
> you only noticed it after upgrading from 2.16.0 to 2.16.1.
> Do you recall anything else you've changed?
> 
> - Lars
> 

Re: "git branch" issue in 2.16.1

[Lars Schneider]

> On 07 Feb 2018, at 19:09, Jason Racey <jason@eluvio.com> wrote:
> 
> Hi Lars,
> 
> Here’s what I’m certain of:
> 
> 1. Just set up a new MacBook Pro at work. Git version 2.16.1 installed via Homebrew. “git branch” command always displays the list of branches in the less pager, regardless of number of branches or screen size. I’ve never seen this happen before.
> 2. Checked the “git branch” behavior on my personal MacBook Pro. Git version there is 2.16.0. Does not have this always paging behavior.
> 3. Ran "brew upgrade git" on personal MacBook Pro. Git upgraded to 2.16.1.
> 4. Checked the “git branch” behavior on my personal MacBook Pro after version upgrade. Pager now always used regardless of number of branches or screen size. Oh no! Seems like there might be a bug in the new version, better email the git bug list in just to be safe.
> 5. Meanwhile research problem on Stack Overflow. Mitigated (though not really fixed) issue on both machines with this command: git config --global core.pager ‘’
> 

That's great! Thank you. Can you share your exact OS version running
on your work and personal machine? Plus, what shell do you use and
what terminal application?

Thanks,
Lars


PS: Please don't top post on the git mailing list :-)
https://en.wikipedia.org/wiki/Posting_style


> Thanks!
> 
> - Jason
> 
> 
>> On Feb 7, 2018, at 9:54 AM, Lars Schneider <larsxschneider@gmail.com> wrote:
>> 
>> 
>>> On 06 Feb 2018, at 21:05, Stefan Beller <sbeller@google.com> wrote:
>>> 
>>> On Tue, Feb 6, 2018 at 11:57 AM, Todd Zullinger <tmz@pobox.com> wrote:
>>>> Hi Jason,
>>>> 
>>>> Jason Racey wrote:
>>>>> After upgrading git from 2.16.0 to 2.16.1 (via Homebrew -
>>>>> I’m on macOS) I noticed that the “git branch” command
>>>>> appears to display the branch listing in something similar
>>>>> to a vi editor - though not quite the same. I don’t know
>>>>> the technical term for this state. You can’t actually edit
>>>>> the output of the command, but you’re in a state where you
>>>>> have to type “q” to exit and then the list disappears.
>>>>> It’s very inconvenient and it doesn’t seem like it was by
>>>>> design. I’m using zsh in iTerm2 if that helps. Thanks.
>>>> 
>>>> In 2.16.0 `git branch --list` is sent to a pager by default.
>>>> (Without arguments, --list is the default, so this applies
>>>> to `git branch`).
>>>> 
>>>> You can set pager.branch to false to disable this in the
>>>> config, or use git --no-pager branch to do so for a single
>>>> invocation.
>>>> 
>>>> I can't say why you're seeing this with 2.16.1 and not
>>>> 2.16.0, but I'm not familiar with homebrew, so perhaps
>>>> something didn't work as intended in 2.16.0.
>>>> 
>>> 
>>> Maybe the number of branches changed since then?
>>> As the pager only comes to life when the output fills
>>> more than your screen. Quick workarounds:
>>> * buy a bigger screen
>>> * have fewer branches.
>> 
>> Hmmm... there might be more to it. I just noticed the
>> pager behavior on macOS, too. Consider this call:
>> 
>> $ git diff --shortstat
>> 
>> This should generate at most one line of output. On Linux
>> the pager is never used. On macOS the pager is always used.
>> 
>> I tried older versions of Git on macOS and experienced the
>> same behavior.
>> 
>> @Jason: That might be a bug on macOS. However, I am surprised
>> you only noticed it after upgrading from 2.16.0 to 2.16.1.
>> Do you recall anything else you've changed?
>> 
>> - Lars
>> 
> 

Re: "git branch" issue in 2.16.1

[Jeff King]

On Wed, Feb 07, 2018 at 06:54:23PM +0100, Lars Schneider wrote:

> > Maybe the number of branches changed since then?
> > As the pager only comes to life when the output fills
> > more than your screen. Quick workarounds:
> > * buy a bigger screen
> > * have fewer branches.
> 
> Hmmm... there might be more to it. I just noticed the
> pager behavior on macOS, too. Consider this call:
> 
> $ git diff --shortstat
> 
> This should generate at most one line of output. On Linux
> the pager is never used. On macOS the pager is always used.
> 
> I tried older versions of Git on macOS and experienced the
> same behavior.

Keep in mind that we always run the pager, since we don't know ahead of
time how much output will be generated. It's just that with certain
configurations of "less", it may exit if it sees EOF before there's a
whole screen worth of data.

This is controlled by the "-F" option. By default, Git will set LESS=FRX
in the environment if you do not already have a $LESS environment. So
some other possibilities are:

  1. You have $LESS in your environment (without "F") on one platform
     but not the other.

  2. Git was built with a different PAGER_ENV Makefile variable on one
     platform versus the other (that's what controls the baked-in LESS
     defaults).

  3. "less" somehow behaves differently on macOS. The "F" behavior is
     quite old, but possibly there's some platform-specific bug.

-Peff

Re: "git branch" issue in 2.16.1

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> Keep in mind that we always run the pager, since we don't know ahead of
> time how much output will be generated. It's just that with certain
> configurations of "less", it may exit if it sees EOF before there's a
> whole screen worth of data.
>
> This is controlled by the "-F" option. By default, Git will set LESS=FRX
> in the environment if you do not already have a $LESS environment. So
> some other possibilities are:
>
>   1. You have $LESS in your environment (without "F") on one platform
>      but not the other.
>
>   2. Git was built with a different PAGER_ENV Makefile variable on one
>      platform versus the other (that's what controls the baked-in LESS
>      defaults).
>
>   3. "less" somehow behaves differently on macOS. The "F" behavior is
>      quite old, but possibly there's some platform-specific bug.

4. Between your two runs, you do not have that many branches to fill
   the screen vertically in either case, but only in one case you
   have a branch with very long name (or perhaps "branch -l -v" made
   a line longer), and you have S and F in LESS environment.  The
   case that shows branches with short names will cause pager to
   exit at the end, while the other one, because it wants to allow
   you to scroll sideways, will not.

Re: "git branch" issue in 2.16.1

[Lars Schneider]

> On 07 Feb 2018, at 21:08, Jeff King <peff@peff.net> wrote:
> 
> On Wed, Feb 07, 2018 at 06:54:23PM +0100, Lars Schneider wrote:
> 
>>> Maybe the number of branches changed since then?
>>> As the pager only comes to life when the output fills
>>> more than your screen. Quick workarounds:
>>> * buy a bigger screen
>>> * have fewer branches.
>> 
>> Hmmm... there might be more to it. I just noticed the
>> pager behavior on macOS, too. Consider this call:
>> 
>> $ git diff --shortstat
>> 
>> This should generate at most one line of output. On Linux
>> the pager is never used. On macOS the pager is always used.
>> 
>> I tried older versions of Git on macOS and experienced the
>> same behavior.
> 
> Keep in mind that we always run the pager, since we don't know ahead of
> time how much output will be generated. It's just that with certain
> configurations of "less", it may exit if it sees EOF before there's a
> whole screen worth of data.
> 
> This is controlled by the "-F" option. By default, Git will set LESS=FRX
> in the environment if you do not already have a $LESS environment. So
> some other possibilities are:
> 
>  1. You have $LESS in your environment (without "F") on one platform
>     but not the other.

I think that's it. On my system LESS is defined to "-R".

This opens the pager:

	$ echo "TEST" | less

This does not open the pager:

	$ echo "TEST" | less -FRX

That means "F" works on macOS but Git doesn't set it because LESS is
already in my environment.

Question is, why is LESS set that way on my system? I can't find
it in .bashrc .bash_profile .zshrc and friends.

- Lars


> 
>  2. Git was built with a different PAGER_ENV Makefile variable on one
>     platform versus the other (that's what controls the baked-in LESS
>     defaults).
> 
>  3. "less" somehow behaves differently on macOS. The "F" behavior is
>     quite old, but possibly there's some platform-specific bug.
> 
> -Peff

Re: "git branch" issue in 2.16.1

[Jeff King]

On Wed, Feb 07, 2018 at 11:20:08PM +0100, Lars Schneider wrote:

> >  1. You have $LESS in your environment (without "F") on one platform
> >     but not the other.
> 
> I think that's it. On my system LESS is defined to "-R".
> 
> This opens the pager:
> 
> 	$ echo "TEST" | less
> 
> This does not open the pager:
> 
> 	$ echo "TEST" | less -FRX
> 
> That means "F" works on macOS but Git doesn't set it because LESS is
> already in my environment.
> 
> Question is, why is LESS set that way on my system? I can't find
> it in .bashrc .bash_profile .zshrc and friends.

There's also /etc/bash.bashrc, /etc/profile, etc. I don't know what's
normal in the mac world. You can try running:

  bash -ix 2>&1 </dev/null | grep LESS

to see what your startup code is doing. I don't know of a good way to
correlate that with the source files, though. Or even to ask bash which
startup files it's looking in.

-Peff

Re: "git branch" issue in 2.16.1

[Lars Schneider]

> On 08 Feb 2018, at 09:50, Jeff King <peff@peff.net> wrote:
> 
> On Wed, Feb 07, 2018 at 11:20:08PM +0100, Lars Schneider wrote:
> 
>>> 1. You have $LESS in your environment (without "F") on one platform
>>>    but not the other.
>> 
>> I think that's it. On my system LESS is defined to "-R".
>> 
>> This opens the pager:
>> 
>> 	$ echo "TEST" | less
>> 
>> This does not open the pager:
>> 
>> 	$ echo "TEST" | less -FRX
>> 
>> That means "F" works on macOS but Git doesn't set it because LESS is
>> already in my environment.
>> 
>> Question is, why is LESS set that way on my system? I can't find
>> it in .bashrc .bash_profile .zshrc and friends.
> 
> There's also /etc/bash.bashrc, /etc/profile, etc. I don't know what's
> normal in the mac world. You can try running:
> 
>  bash -ix 2>&1 </dev/null | grep LESS
> 
> to see what your startup code is doing. I don't know of a good way to
> correlate that with the source files, though. Or even to ask bash which
> startup files it's looking in.

Unfortunately, this command doesn't work for me.

I ask around and most of my coworkers have LESS="-R".
Only the coworker that doesn't really use his Mac and has
no customizations does not have $LESS defined.

Therefore, I think it is likely some third party component
that sets $LESS.

@Jason:
Do you have homebrew, iTerm2, and/or oh-my-zsh installed?

- Lars

Re: "git branch" issue in 2.16.1

[Lars Schneider]

> On 08 Feb 2018, at 12:13, Lars Schneider <larsxschneider@gmail.com> wrote:
> 
> 
>> On 08 Feb 2018, at 09:50, Jeff King <peff@peff.net> wrote:
>> 
>> On Wed, Feb 07, 2018 at 11:20:08PM +0100, Lars Schneider wrote:
>> 
>>>> 1. You have $LESS in your environment (without "F") on one platform
>>>>   but not the other.
>>> 
>>> I think that's it. On my system LESS is defined to "-R".
>>> 
>>> This opens the pager:
>>> 
>>> 	$ echo "TEST" | less
>>> 
>>> This does not open the pager:
>>> 
>>> 	$ echo "TEST" | less -FRX
>>> 
>>> That means "F" works on macOS but Git doesn't set it because LESS is
>>> already in my environment.
>>> 
>>> Question is, why is LESS set that way on my system? I can't find
>>> it in .bashrc .bash_profile .zshrc and friends.
>> 
>> There's also /etc/bash.bashrc, /etc/profile, etc. I don't know what's
>> normal in the mac world. You can try running:
>> 
>> bash -ix 2>&1 </dev/null | grep LESS
>> 
>> to see what your startup code is doing. I don't know of a good way to
>> correlate that with the source files, though. Or even to ask bash which
>> startup files it's looking in.
> 
> Unfortunately, this command doesn't work for me.
> 
> I ask around and most of my coworkers have LESS="-R".
> Only the coworker that doesn't really use his Mac and has
> no customizations does not have $LESS defined.
> 
> Therefore, I think it is likely some third party component
> that sets $LESS.
> 
> @Jason:
> Do you have homebrew, iTerm2, and/or oh-my-zsh installed?

Ha. I found it it! It is indeed oh-my-zsh:
https://github.com/robbyrussell/oh-my-zsh/blob/master/lib/misc.zsh#L23

Let's see if oh-my-zsh is willing to change that...

- Lars

Re: "git branch" issue in 2.16.1

[Kevin Daudt]

On Thu, Feb 08, 2018 at 12:27:07PM +0100, Lars Schneider wrote:
> 
> > On 08 Feb 2018, at 12:13, Lars Schneider <larsxschneider@gmail.com> wrote:
> > 
> > 
> >> On 08 Feb 2018, at 09:50, Jeff King <peff@peff.net> wrote:
> >> 
> >> On Wed, Feb 07, 2018 at 11:20:08PM +0100, Lars Schneider wrote:
> >> 
> >>>> 1. You have $LESS in your environment (without "F") on one platform
> >>>>   but not the other.
> >>> 
> >>> I think that's it. On my system LESS is defined to "-R".
> >>> 
> >>> This opens the pager:
> >>> 
> >>> 	$ echo "TEST" | less
> >>> 
> >>> This does not open the pager:
> >>> 
> >>> 	$ echo "TEST" | less -FRX
> >>> 
> >>> That means "F" works on macOS but Git doesn't set it because LESS is
> >>> already in my environment.
> >>> 
> >>> Question is, why is LESS set that way on my system? I can't find
> >>> it in .bashrc .bash_profile .zshrc and friends.
> >> 
> >> There's also /etc/bash.bashrc, /etc/profile, etc. I don't know what's
> >> normal in the mac world. You can try running:
> >> 
> >> bash -ix 2>&1 </dev/null | grep LESS
> >> 
> >> to see what your startup code is doing. I don't know of a good way to
> >> correlate that with the source files, though. Or even to ask bash which
> >> startup files it's looking in.
> > 
> > Unfortunately, this command doesn't work for me.
> > 
> > I ask around and most of my coworkers have LESS="-R".
> > Only the coworker that doesn't really use his Mac and has
> > no customizations does not have $LESS defined.
> > 
> > Therefore, I think it is likely some third party component
> > that sets $LESS.
> > 
> > @Jason:
> > Do you have homebrew, iTerm2, and/or oh-my-zsh installed?
> 
> Ha. I found it it! It is indeed oh-my-zsh:
> https://github.com/robbyrussell/oh-my-zsh/blob/master/lib/misc.zsh#L23
> 
> Let's see if oh-my-zsh is willing to change that...
> 
> - Lars

I've just added unset LESS in my .zshrc, but for most users it would be
better if they don't set it at all.

Re: "git branch" issue in 2.16.1

[Lars Schneider]

> On 08 Feb 2018, at 17:19, Kevin Daudt <me@ikke.info> wrote:
> 
> On Thu, Feb 08, 2018 at 12:27:07PM +0100, Lars Schneider wrote:
>> 
>>> On 08 Feb 2018, at 12:13, Lars Schneider <larsxschneider@gmail.com> wrote:
>>> 
>>> 
>>>> On 08 Feb 2018, at 09:50, Jeff King <peff@peff.net> wrote:
>>>> 
>>>> On Wed, Feb 07, 2018 at 11:20:08PM +0100, Lars Schneider wrote:
>>>> 
>>>>>> 1. You have $LESS in your environment (without "F") on one platform
>>>>>>  but not the other.
>>>>> 
>>>>> I think that's it. On my system LESS is defined to "-R".
>>>>> 
>>>>> This opens the pager:
>>>>> 
>>>>> 	$ echo "TEST" | less
>>>>> 
>>>>> This does not open the pager:
>>>>> 
>>>>> 	$ echo "TEST" | less -FRX
>>>>> 
>>>>> That means "F" works on macOS but Git doesn't set it because LESS is
>>>>> already in my environment.
>>>>> 
>>>>> Question is, why is LESS set that way on my system? I can't find
>>>>> it in .bashrc .bash_profile .zshrc and friends.
>>>> 
>>>> There's also /etc/bash.bashrc, /etc/profile, etc. I don't know what's
>>>> normal in the mac world. You can try running:
>>>> 
>>>> bash -ix 2>&1 </dev/null | grep LESS
>>>> 
>>>> to see what your startup code is doing. I don't know of a good way to
>>>> correlate that with the source files, though. Or even to ask bash which
>>>> startup files it's looking in.
>>> 
>>> Unfortunately, this command doesn't work for me.
>>> 
>>> I ask around and most of my coworkers have LESS="-R".
>>> Only the coworker that doesn't really use his Mac and has
>>> no customizations does not have $LESS defined.
>>> 
>>> Therefore, I think it is likely some third party component
>>> that sets $LESS.
>>> 
>>> @Jason:
>>> Do you have homebrew, iTerm2, and/or oh-my-zsh installed?
>> 
>> Ha. I found it it! It is indeed oh-my-zsh:
>> https://github.com/robbyrussell/oh-my-zsh/blob/master/lib/misc.zsh#L23
>> 
>> Let's see if oh-my-zsh is willing to change that...
>> 
>> - Lars
> 
> I've just added unset LESS in my .zshrc, but for most users it would be
> better if they don't set it at all.

I proposed this instead:
https://github.com/robbyrussell/oh-my-zsh/pull/6611

Maybe you can chime in there?

Thanks,
Lars