Duplicated lines when moving in pager #3235
Comments
Could you bisect through the snapshots? |
|
@dscho Sure. |
Could you diff the |
$ diff -Nur 67e748c de4a643
--- 67e748c 2021-05-25 19:05:01.143102900 +0200
+++ de4a643 2021-05-25 19:06:40.413573800 +0200
@@ -2,33 +2,33 @@
apr-util 1.6.1-1
bash 4.4.023-1
bzip2 1.0.8-2
-ca-certificates 20190110-1
+ca-certificates 20210119-1
coreutils 8.32-1
diffutils 3.7-1
docx2txt 1.4-1
dos2unix 7.4.2-1
expat 2.3.0-1
-file 5.40-1
+file 5.40-2
findutils 4.8.0-1
gawk 5.0.0-1
gcc-libs 10.2.0-1
gettext 0.19.8.1-1
-git-extra 1.1.520.98cc8ec-1
+git-extra 1.1.523.d946137-1
git-flow 1.12.3-1
-glib2 2.66.6-1
+glib2 2.68.1-1
gmp 6.2.1-1
gnupg 2.2.27-1
grep 3.1-1
gzip 1.10-1
heimdal-libs 7.5.0-3
icu 68.2-1
-less 563-2
+less 581-1
libasprintf 0.19.8.1-1
libassuan 2.5.5-1
libbz2 1.0.8-2
libcbor 0.8.0-1
-libcrypt 2.1-2
-libcurl 7.76.0-1
+libcrypt 2.1-3
+libcurl 7.76.1-1
libedit 20210216_3.1-1
libexpat 2.3.0-1
libffi 3.3-1
@@ -55,60 +55,60 @@
libpsl 0.21.1-2
libreadline 8.1.0-1
libsasl 2.1.27-1
-libserf 1.3.9-5
-libsqlite 3.35.4-1
+libserf 1.3.9-6
+libsqlite 3.35.5-1
libssh2 1.9.0-1
libtasn1 4.16.0-1
libunistring 0.9.10-1
libutil-linux 2.35.2-1
-libxml2 2.9.10-7
-libxslt 1.1.34-3
+libxml2 2.9.10-9
+libxslt 1.1.34-4
mingw-w64-x86_64-antiword 0.37-2
mingw-w64-x86_64-brotli 1.0.9-2
mingw-w64-x86_64-bzip2 1.0.8-2
mingw-w64-x86_64-ca-certificates 20200601-3
mingw-w64-x86_64-c-ares 1.17.1-1
mingw-w64-x86_64-connect 1.105-2
-mingw-w64-x86_64-curl 7.76.0-1
+mingw-w64-x86_64-curl 7.76.1-1
mingw-w64-x86_64-expat 2.2.10-1
-mingw-w64-x86_64-gcc-libs 10.2.0-9
+mingw-w64-x86_64-gcc-libs 10.3.0-2
mingw-w64-x86_64-gettext 0.19.8.1-10
-mingw-w64-x86_64-git 2.31.1.windows.1.28.g67e748cc61.20210408225318-1
+mingw-w64-x86_64-git 2.32.0.rc0.windows.1.4.gde4a643419.20210517161711-1
mingw-w64-x86_64-git-credential-manager 1.20.0-1
-mingw-w64-x86_64-git-credential-manager-core 2.0.394.50751-1
-mingw-w64-x86_64-git-doc-html 2.31.1.windows.1.28.g67e748cc61.20210408225318-1
+mingw-w64-x86_64-git-credential-manager-core 2.0.435.9025-1
+mingw-w64-x86_64-git-doc-html 2.32.0.rc0.windows.1.4.gde4a643419.20210517161711-1
mingw-w64-x86_64-git-lfs 2.13.3-1
-mingw-w64-x86_64-gmp 6.2.1-1
-mingw-w64-x86_64-gnutls 3.7.0-2
+mingw-w64-x86_64-gmp 6.2.1-2
+mingw-w64-x86_64-gnutls 3.7.1-1
mingw-w64-x86_64-jansson 2.13.1-1
-mingw-w64-x86_64-jemalloc 5.2.1-1
-mingw-w64-x86_64-libffi 3.3-3
+mingw-w64-x86_64-jemalloc 5.2.1-2
+mingw-w64-x86_64-libffi 3.3-4
mingw-w64-x86_64-libiconv 1.16-2
mingw-w64-x86_64-libidn2 2.3.0-1
mingw-w64-x86_64-libmetalink 0.1.3-3
-mingw-w64-x86_64-libssh2 1.9.0-2
+mingw-w64-x86_64-libssh2 1.9.0-3
mingw-w64-x86_64-libsystre 1.0.1-4
-mingw-w64-x86_64-libtasn1 4.16.0-1
+mingw-w64-x86_64-libtasn1 4.16.0-2
mingw-w64-x86_64-libtre-git r128.6fb7206-2
-mingw-w64-x86_64-libunistring 0.9.10-2
-mingw-w64-x86_64-libwinpthread-git 9.0.0.6154.e37b315b-1
+mingw-w64-x86_64-libunistring 0.9.10-3
+mingw-w64-x86_64-libwinpthread-git 9.0.0.6184.ab0fa5ad-1
mingw-w64-x86_64-libzip 1.7.3-1
mingw-w64-x86_64-mpc 1.2.1-1
mingw-w64-x86_64-mpfr 4.1.0-3
-mingw-w64-x86_64-nettle 3.7-1
+mingw-w64-x86_64-nettle 3.7-2
mingw-w64-x86_64-nghttp2 1.41.0-1
mingw-w64-x86_64-odt2txt 0.5-2
mingw-w64-x86_64-openssl 1.1.1.k-1
-mingw-w64-x86_64-pcre 8.44-2
+mingw-w64-x86_64-pcre 8.44-3
mingw-w64-x86_64-pcre2 10.36-1
-mingw-w64-x86_64-tcl 8.6.11-2
-mingw-w64-x86_64-tk 8.6.11.1-1
+mingw-w64-x86_64-tcl 8.6.11-3
+mingw-w64-x86_64-tk 8.6.11.1-2
mingw-w64-x86_64-wineditline 2.205-3
mingw-w64-x86_64-wintoast 1.0.0.181.9b0663d-1
mingw-w64-x86_64-xz 5.2.5-2
mingw-w64-x86_64-zlib 1.2.11-9
-mingw-w64-x86_64-zstd 1.4.8-2
-mintty 1~3.4.7-1
+mingw-w64-x86_64-zstd 1.5.0-1
+mintty 1~3.5.0-1
mpfr 4.1.0-1
msys2-runtime 3.1.7-5
nano 5.6.1-1
@@ -156,13 +156,13 @@
tcl 8.6.10-1
tig 2.5.3-1
unzip 6.0-2
-vim 8.2.2689-1
+vim 8.2.2689-2
which 2.21-2
winpty 0.4.3-1
zlib 1.2.11-1
-filesystem 2021.03-6
+filesystem 2021.04-4
dash 0.5.11.3-1
-rebase 4.4.4-2
+rebase 4.4.4-3
util-linux 2.35.2-1
unzip 6.0-2
mingw-w64-x86_64-xpdf-tools 4.00-1
(base)Looks like |
|
I tested using |
|
It shows that
Note: not all version numbers between those versions are available for download, see http://greenwoodsoftware.com/less/download.html. You could also see whether the two newer versions fix the issue. |
|
http://greenwoodsoftware.com/less/download.html does not list any versions between 563 and 581.2 numerically. The changes between less 563 and 581 include "Patch for Windows virtual terminal", which sets variables related to line wrapping. I don't know whether that causes the problem, though. The changes between less 581 and 581.2 don't include anything relevant. |
|
Following an enlarging resize of the Git Bash window, paging in I've reverted to 2.31.1 because of it. |
Excellent analysis. Did you get a chance to test those changes? |
|
(And yes, I bet that |
No, I don't have a computer available for such use. |
|
Okay. Just leaving this here for posterity: we should probably add a patch to |
|
Would #3235 (comment) (my comment above) be caused by this issue, or something else? |
|
I thought perhaps |
from Jason Shirk and Jason Hood.
@t-b wrote "Problem shows in cmd and in Windows terminal" and the screen shot looks like the "Eingabeaufforderung" window was created by conhost. I don't think checking |
|
@KalleOlaviNiemitalo Yes the issue is present in "Windows terminal" and a plain cmd. |
|
The SetConsoleMode calls in less 581 are not executed, and SetConsoleMode is not in the import table. The issue does not occur if I run If I run COLUMNS=80 is however not in the PEB of the less.exe process. I guess MSYS keeps its environment variables somewhere else. If I It seems the problem is that something injects the incorrect value COLUMNS=80 and less 581 now trusts that while less 563 does not. |
|
gwsw/less@bb0ee4e made the COLUMNS variable take precedence. |
|
Workaround: Which shows that the incorrect COLUMNS value is received from the parent process, rather than generated by some library that less uses. |
|
Git sets COLUMNS in setup_pager: Lines 109 to 118 in 4c20499 term_columns tries to read the window size from the COLUMNS environment variable or with TIOCGWINSZ, and defaults to 80 if neither works: Lines 160 to 171 in 4c20499 I have not verified with a debugger that this is what passes the incorrect COLUMNS=80 to less, but it looks very likely, So, I wonder why TIOCGWINSZ doesn't work, then. |
|
I think I've found the same or a very similar bug when used Git Bash. This Git was installed with default installation options. How to reproduce:
One of the diffs that you normally should see is the following: But for some reason you see it distorted:
As you can see in the attached screenshot the problematic line is splitted into two parts. When it's the last line of the scrolled output the first part is shown and if you continue to scroll down the second part is show instead. A similar bug will be triggered if you run it without colors, i.e. P.S. this bug was found when I worked on the following PR in the mainstream Git repo: |
In git.exe version 2.32.0.windows.1 (amd64), setup_pager apparently starts at git+0x19a3f0, and term_columns is inlined:
That means the I think what this needs is:
|
|
@KalleOlaviNiemitalo excellent analysis!
I guess we will have to fix the MSYS2 runtime to set the correct |
|
Hmm. I cannot find any mention of A workaround in the meantime might be to call this in your shell: export COLUMNS=$(tput cols) |
|
Bash can set the COLUMNS variable by itself, and update it when the terminal is resized. It does not export COLUMNS to child processes by default but However, if I resize the terminal while the pager is running, then Bash does not update COLUMNS until I According to be11f7a, setup_pager adds COLUMNS to the environment for the sake of Git child processes. It doesn't seem intended for the pager itself, but now unfortunately affects that too. compat/winansi.c already contains a couple of GetConsoleScreenBufferInfo calls. I imagine term_columns could likewise call that. I'm not sure whether term_columns should use dwSize or srWindow from CONSOLE_SCREEN_BUFFER_INFO. |
|
I just tested this, and it seems to work around the problem in an acceptable manner: diff --git a/pager.c b/pager.c
index 3d37dd7adaa2..b84668eddca2 100644
--- a/pager.c
+++ b/pager.c
@@ -111,11 +111,13 @@ void setup_pager(void)
* to get the terminal size. Let's grab it now, and then set $COLUMNS
* to communicate it to any sub-processes.
*/
+#if !defined(WIN32) || defined(TIOCGWINSZ)
{
char buf[64];
xsnprintf(buf, sizeof(buf), "%d", term_columns());
setenv("COLUMNS", buf, 0);
}
+#endif
setenv("GIT_PAGER_IN_USE", "true", 1);
The rationale: if we are on Windows, we might very well not have a working ncurses, in which case we definitely want to stop trying to be clever about setting |
Since gwsw/less@bb0ee4e76c2, `less` prefers the `COLUMNS` variable over asking ncurses itself. This is typically not a problem because we ask `TIOCGWINSZ` in Git, to determine the correct value for `COLUMNS`. However, on Windows it _is_ a problem because Git for Windows' Bash (and `less.exe`) uses the MSYS2 runtime while `git.exe` does _not_, and therefore we never get the correct value in Git, but `less.exe` has no problem obtaining it. Let's not override `COLUMNS` in that case. This fixes git-for-windows#3235 Signed-off-by: Johannes Schindelin <[email protected]>
|
@t-b could I bother you to test the build artifacts of https://github.com/git-for-windows/git/actions/runs/936192709 once the run is done? |
|
@dscho Sure. I can not reproduce the bug with that (git version 2.32.0.windows.1.8.g262eaa2f4f.20210614151600) version. |
This fixes my use case as well. Thank you. |
Since gwsw/less@bb0ee4e76c2, `less` prefers the `COLUMNS` variable over asking ncurses itself. This is typically not a problem because we ask `TIOCGWINSZ` in Git, to determine the correct value for `COLUMNS`, and then set that environment variable. However, on Windows it _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). 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. Note: we do this _only_ on Windows, and _only_ if `TIOCGWINSZ` is not defined, to reduce any potential undesired fall-out from this patch. This fixes git-for-windows#3235 Signed-off-by: Johannes Schindelin <[email protected]>
Since gwsw/less@bb0ee4e76c2, `less` prefers the `COLUMNS` variable over asking ncurses itself. This is typically not a problem because we ask `TIOCGWINSZ` in Git, to determine the correct value for `COLUMNS`, and then set that environment variable. However, on Windows it _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). 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. Note: we do this _only_ on Windows, and _only_ if `TIOCGWINSZ` is not defined, to reduce any potential undesired fall-out from this patch. This fixes git-for-windows#3235 Signed-off-by: Johannes Schindelin <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
Another +1 for this build fixing issues I've been seeing with diffing. Thanks for the fix! |
|
Chiming in to note that this issue extends beyond just It turns out that the output of Further experimenting with the |
Excellent news! Unfortunately, according to There are two options I see going forward:
The second option is definitely more work, especially going forward: for now, we inherit the In any case, we would then have to monitor An alternative would be to have a separate repository to monitor the updates, where the website https://www.greenwoodsoftware.com/less/index.html could be scraped (and be stored). I do something like this in a private repository. Maybe it is time to bring this out of the shadows. |
|
@dscho Is there some reason we can't just downgrade to the previous stable release ( |
This is now done here: https://github.com/git-for-windows/track-website-changes |
Due to the way Git for Windows' SDK is set up, this would be non-trivial. There is precendence, of course, see e.g. git-for-windows/git-sdk-64@2121197, git-for-windows/git-sdk-64@8f99f4d, and git-for-windows/git-sdk-64@a60459a. But it has to be done via cloning |
|
Yuck. Well, there's at least a workaround for now in the form of using the |
Even better: the snapshot following the upgrade will already contain the fix. Snapshots are just like full releases, modulo the funny-looking version (but everything else is just the same, down to the very same Azure Pipeline building snapshots and full releases). |
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 gwsw/less@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#3235 Co-authored-by: Junio C Hamano <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
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 gwsw/less@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#3235 Co-authored-by: Junio C Hamano <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
When scrolling in the pager (e.g. in the output of `git log`), [lines were duplicated by mistake](git-for-windows/git#3235). This was fixed. Signed-off-by: Johannes Schindelin <[email protected]>
|
Thank you very much to all involved. That was quite an annoying bug. |
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 gwsw/less@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 #3235 Co-authored-by: Junio C Hamano <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
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 gwsw/less@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 #3235 Co-authored-by: Junio C Hamano <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
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 gwsw/less@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 #3235 Co-authored-by: Junio C Hamano <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
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 gwsw/less@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 #3235 Co-authored-by: Junio C Hamano <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
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 gwsw/less@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 #3235 Co-authored-by: Junio C Hamano <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
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 gwsw/less@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#3235 Co-authored-by: Junio C Hamano <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
Setup
64bit
defaults?
Details
Problem shows in cmd and in Windows terminal. I haven't tried something else.
and then the screen looks like
notice the duplicated line at the top. Somehow the pager thinks it has to break the line. But it is even not correctly broken. When I resize the cmd window it is redrawn correctly. This is especially annoying when the code itself is longer than the magical maximum line length.
This bug was not present with 2.31.x.
The text was updated successfully, but these errors were encountered: