git-log's %<|(-1,trunc) placeholder truncates at column 80, even when tput cols is available.

[anabelle2001]

• I was not able to find an open or closed issue matching what I'm seeing

Setup

• Which version of Git for Windows are you using? Is it 32-bit or 64-bit?

git version 2.47.0.windows.1
cpu: x86_64
built from commit: d53e4648cb65eb75dd8d8a093d17400a18a9a15d
sizeof-long: 4
sizeof-size_t: 8
shell-path: D:/git-sdk-64-build-installers/usr/bin/sh
feature: fsmonitor--daemon
libcurl: 8.10.1
OpenSSL: OpenSSL 3.2.3 3 Sep 2024
zlib: 1.3.1

• Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?

I am using Windows 11:

PS C:\Users\anabelle\git\OncoVISION> cmd.exe /c ver

Microsoft Windows [Version 10.0.26100.3194]

• What options did you set as part of the installation? Or did you choose the
  defaults?

$ cat /etc/install-options.txt
Editor Option: Nano
Custom Editor Path:
Default Branch Option: main
Path Option: Cmd
SSH Option: OpenSSH
Tortoise Option: false
CURL Option: OpenSSL
CRLF Option: CRLFAlways
Bash Terminal Option: MinTTY
Git Pull Behavior Option: Merge
Use Credential Manager: Enabled
Performance Tweaks FSCache: Enabled
Enable Symlinks: Disabled
Enable FSMonitor: Disabled

• Any other interesting things about your environment that might be related
  to the issue you're seeing?

I don't think so.

Details

• Which terminal/shell are you running Git from?

Shells: CMD, Powershell, Bash
Terminal Emulators: VSCode integrated terminal, Windows Terminal (WT.exe)

Locally, i can reproduce the issue on all permutations of the above shells / terminal emulators. The issue does not appear when using WSL.

• What commands did you run to trigger this issue? If you can provide a
  Minimal, Complete, and Verifiable example
  this will help us understand the issue.

In a git repository with some long commit messages, run

git log --pretty=format:'Here is some text to pad out the buffer | %h %<|(-1,trunc)%s'

Example output:

WSL version of git, where the command runs correctly:

[rimrul]

Git determines terminal width from 3 sources:

• ioctl(2), if available (not available on Windows)
• the COLUMNS environment variable, if set
• a hard coded fallback value of 80

[dscho]

Indeed. If you compare git.exe's functionality with tput.exe's, you are comparing apples to oranges. git.exe is a proper Windows executable, while tput.exe depends on the POSIX emulation layer provided by the MSYS2 runtime. If you want git.exe to be in the same league as tput.exe, you need to switch to MSYS2 and use /usr/bin/git.exe instead (narrator's voice: "but you might not like the performance penalty").

So the best work-around you can have for now is to prefix the git log call with COLUMNS=$(tput cols) in your Bash.

[rimrul]

Looking at this some more, Git Bash does set (and update) $COLUMNS, but doesn't export it.

[dscho]

Looking at this some more, Git Bash does set (and update) $COLUMNS, but doesn't export it.

Oh, that's a curious finding! It's probably because that variable is not exported. See my local test:

me@work MINGW64 ~
$ echo $COLUMNS
120

me@work MINGW64 ~
$ git -c alias.env='!env' env | grep COLUMNS

me@work MINGW64 ~
$ export COLUMNS

me@work MINGW64 ~
$ git -c alias.env='!env' env | grep COLUMNS
COLUMNS=120

Which means that after calling export COLUMNS LINES in ~/.bash_profile, @anabelle2001's problem should be addressed?

[rimrul]

Which means that after calling export COLUMNS LINES in ~/.bash_profile, @anabelle2001's problem should be addressed?

Kinda. Probably addressed with side effects, if I'm reading this thread correctly. It seems to mess up curses and ioctl/TIOCGWINSZ for msys2 programms (vim and nano come to mind).

[dscho]

Which means that after calling export COLUMNS LINES in ~/.bash_profile, @anabelle2001's problem should be addressed?

Kinda. Probably addressed with side effects, if I'm reading this thread correctly. It seems to mess up curses and ioctl/TIOCGWINSZ for msys2 programms (vim and nano come to mind).

That's a valid point, programs linking to curses will prefer COLUMNS and LINES, if set, and if you resize, well, that information is incorrect right there.

So maybe we should simply recommend running COLUMNS=$COLUMNS git log ... in scenarios like the reported one, and close this ticket because we cannot really fix this?

[anabelle2001]

It would be nice if there was a solution that wasn't contingent on running git in a bourne-compatible shell. Is it infeasable to just use a native windows API (i.e., GetConsoleScreenBufferInfo, as is used in this stackoverflow answer), to get the terminal size?

[dscho]

Is it infeasable to just use a native windows API (i.e., GetConsoleScreenBufferInfo, as is used in this stackoverflow answer), to get the terminal size?

@anabelle2001 the default for Git Bash is to run in MinTTY, i.e. there is not even a Windows Console. And the only way to access the information you're seeking in that MinTTY is to use a program like tput.exe that relies on the POSIX emulation layer implemented by the MSYS2 runtime. So no, it is not infeasible, but it is far from being as straight-forward as using above-mentioned Win32 API!