"git branch" issue in 2.16.1

> 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.

> 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.
>

> 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.

> 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
> 

> 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 ‘’
> 

> 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
>> 
> 

> > 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.

> 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.

> 
>  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

> >  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.

> 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.

> 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?

> 
> > 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

> 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.

> 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.