In git bash how to increase less's screen width?

user_6749234 0
Viewed 1100

I am using git bash 2.32 on Windows 10.

In git bash after updating to 2.32 I see strange behavior of the command I used for displaying log:

git -c core.pager='less -S -F' log --all --decorate --oneline --graph

As you can see I try to use "a dog" command with less pager configured to quit on EOF and to cut lines whose length exceed the current screen width. But after I updated to 2.32 the output appears to be truncated after 80 symbols which is usually much less than the actual screen width (as shown on the image below).

I am trying to understand how to increase that limit so that less truncates lines that are longer than say 160 symbols or rather the lines that just don't fit the current screen.

Note: I changed the width to 160 and now echo $COLUMNS returns 160 but that didn't help a bit.

Note: I also enabled checkwinsize option for the current session. Also no luck. As can be seen the lines are truncated way too early

windows-10 less windows-console
2 Answers

This is a relatively recent Git-for-Windows bug, with discussion and patches found here in the archives for the Git mailing list. There is a lot of further discussion in this GitHub issue. The bug is to be fixed in the next update of Git-for-Windows.

In the meantime, consider this workaround from KalleOlaviNiemitalo:

git config --global core.pager "env -u COLUMNS less"
user_12564520

The issue "Duplicated lines when moving in pager #3235" will be fixed with Git 2.33 (Q3 2021).
You can test it today with Git for Windows snapshots.

https://user-images.githubusercontent.com/1185677/119397646-b889e480-bcd6-11eb-882d-0821a97b7eeb.png

(see duplicate lines at the top)

Root cause: when we cannot figure out how wide the terminal is, we use a fallback value of 80 ourselves (which cannot be avoided), but when we run the pager, we export it in COLUMNS, which forces the pager to use the hardcoded value, even when the pager is perfectly capable to figure it out itself.

Stop exporting COLUMNS when we fall back on the hardcoded default value for our own use.

See commit 9b6e2c8 (21 Jun 2021) by Johannes Schindelin (dscho).
(Merged by Junio C Hamano -- gitster -- in commit 32d6280, 08 Jul 2021)

pager: avoid setting COLUMNS when we're guessing its value

Co-authored-by: Junio C Hamano
Signed-off-by: Johannes Schindelin

We query TIOCGWINSZ in Git to determine the correct value for COLUMNS, and then set that environment variable.

If TIOCGWINSZ is not available, we fall back to the hard-coded value 80 and still set the environment variable.

On Windows this is a problem.
The reason is that Git for Windows uses a version of less that relies on the MSYS2 runtime to interact with the pseudo terminal (typically inside a MinTTY window, which is also aware of the MSYS2 runtime).

Both MinTTY and less.exe interact with that pseudo terminal via ioctl() calls (which the MSYS2 runtime emulates even if there is no such thing on Windows).

Since https://github.com/gwsw/less/commit/bb0ee4e76c2, less prefers the COLUMNS variable over asking ncurses itself.

But git.exe itself is not aware of the MSYS2 runtime, or for that matter of that pseudo terminal, and has no way to call ioctl() or TIOCGWINSZ.

Therefore, git.exe will fall back to hard-coding 80 columns, no matter what the actual terminal size is.

But less.exe is totally able to interact with the MSYS2 runtime and would not actually require Git's help (which actually makes things worse here).
So let's not override COLUMNS on Windows.

Let's just not set COLUMNS unless we managed to query the actual value from the terminal.

This fixes git-for-windows/git issue 3235

VonC_63090
Related