Repository navigation
After exiting commit editor whole console get cleared #5303
Description
Setup
- Which version of Git for Windows are you using? Is it 32-bit or 64-bit?
$ git --version --build-options
git version 2.47.1.windows.1
cpu: x86_64
built from commit: 2cd22437f64229935dc564db969cbcbfed5e9045
sizeof-long: 4
sizeof-size_t: 8
shell-path: D:/git-sdk-64-build-installers/usr/bin/sh
feature: fsmonitor--daemon
libcurl: 8.11.0
OpenSSL: OpenSSL 3.2.3 3 Sep 2024
zlib: 1.3.1
Older version git version 2.24.1.windows.2 do not had this problems.
- Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?
$ cmd.exe /c ver
Microsoft Windows [Version 10.0.19045.5131]
- What options did you set as part of the installation? Or did you choose the
defaults?
# One of the following:
> type "C:\Program Files\Git\etc\install-options.txt"
> type "C:\Program Files (x86)\Git\etc\install-options.txt"
> type "%USERPROFILE%\AppData\Local\Programs\Git\etc\install-options.txt"
> type "$env:USERPROFILE\AppData\Local\Programs\Git\etc\install-options.txt"
$ cat /etc/install-options.txt
Editor Option: VIM
Custom Editor Path:
Default Branch Option:
Path Option: BashOnly
SSH Option: OpenSSH
Tortoise Option: false
CURL Option: OpenSSL
CRLF Option: CRLFCommitAsIs
Bash Terminal Option: MinTTY
Git Pull Behavior Option: FFOnly
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?
Added tmux with libs from libevent from msys2
Details
- Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other
Bash with mintty
- 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.
When using vim whole console get cleared, I boils down this problem to:
git config core.editor "f(){ echo $'\e[?1049h\e[22;0;0t'; echo \"Write to \$1\"; cat > \"\$1\"; echo $'\e[?1049l\e[23;0;0;t'; }; f"
git commit --amend
- What did you expect to occur after running these commands?
I can see content in console like (all console history before commit):
[10:08][Yankes:~/prog/dummy] (master)
$ tmux
[11:08][Yankes:~/prog/dummy] (master)
$ vim
[12:08][Yankes:~/prog/dummy] (master)
$ git config core.editor "f(){ echo $'\e[?1049h\e[22;0;0t'; echo \"Write to \$1\"; cat > \"\$1\"; echo $'\e[?1049l\e[23;0;0;t'; }; f" && git commit --amend
hint: Waiting for your editor to close the file...
[master ea17ecf] eeee
Date: Sat Dec 7 00:06:33 2024 +0100
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 foo
[12:13][Yankes:~/prog/dummy] (master)
$
- What actually happened instead?
Lot of empty space and final commit result message:
hint: Waiting for your editor to close the file...
[t-feature/merge-appka c315b8b668] aaaa
Date: Fri Dec 6 16:22:31 2024 +0100
1 file changed, 1 insertion(+)
create mode 100644 dummy
[12:13][Yankes:~/prog/dummy] (master)
$
- If the problem was occurring with a specific repository, can you provide the
URL to that repository to help us with testing?
No, clean repository is enough.
Overall vim have too some problems with gathering info about terminal and mess up my colors
when run through git.
Activity
dscho commentedon Mar 3, 2025
Isn't this more an issue for https://github.com/mintty/mintty?
Also, you assume quite a bit of context without trying to help any reader along should they lack that context. What are you trying to accomplish with the
\e[?1049h/\e[?1049lsequences? And what with the\e[22;0;0t/\e[23;0;0tones? I can see no description of them on https://github.com/mintty/mintty/wiki/CtrlSeqs, and I have to admit that I feel quite annoyed by the terseness of this issue description as well as the willingness to put quite the burden and time tax on anyone who dares to try to make any sense of this report. I find it very inconsiderate to write such a report that would require such a lot of research merely to understand what the bug report is trying to say.Yankes commentedon Mar 3, 2025
I do not think is problem with mintty as same happens under tmux and problem appear only after updating git version.
As for my example, template ask for minimal example, and I simply could have broken vim config that could interfere with git.
Therefore I extracted control codes that vim send to swap screens in xterm that work fine in other contexts but when git run vim something get confused.
I was hoping that two line example that allow reproduce bug is enough (as this exact code work on other machines with older git or diffret git distributions).
Its hard for me to add more context how its work as only thing I could provide some random pages I find when I look what escape codes vim output and make sense of this why it with git mess up my console.
As far I understand
\e[?1049hask terminal to switch to temporary screen without scroll back (typical vim usage)\e[?1049lask terminal to go back to normal terminal screen with previous content (typical used by bash)for
\e[22;0;0tand\e[23;0;0;tI do not know what point of it is, simply vim output them. when I now remove it problem still presentient. I could probably reduce it more but as I could break git in less than 200 characters I thought this is minimal enough.dscho commentedon Mar 3, 2025
I cannot promise anything, but there is an off-chance that git-for-windows/msys2-runtime#87 might fix your problem. To test, download the install artifact from https://github.com/git-for-windows/msys2-runtime/actions/runs/13628995018?pr=87#artifacts, extract its
usr\bin\msys-2.0.dlland (temporarily) replace your regular Git installation's version, then try again?Yankes commentedon Mar 3, 2025
After replacing msys dll it still behave same, but looking on description of that error it could be related.
I will maybe install fresh version too as I did not update it from time of report.
TomasMalecek commentedon Mar 5, 2025
I am facing the same issue even under different circumstances -- after using a pager, e.g., via
git diff.In my ~/.profile, I have
export LESS=RSas I want the pager's content not to pollute the scrollback. After an update (sadly I am not sure about the original version), I started getting this weird behavior where a part of the previous scrollback content gets overwritten with blank space. It happens when Vim (core.editor) or Less (core.pager) are executed. When the scrollback is long enough, it can be seen that the top is OK and only the last several lines (whose number exactly matches the height of the window) are cleared.By the way, while trying to quickly get some scrollback content, I came across a separate issue and reported it as #5468. The details of my setup are mentioned there. I also reproduced both issues on the latest snapshot (built from 1424e27), specifically its portable version.
TomasMalecek commentedon Mar 5, 2025
I tried playing with the options in the LESS environment variable and with core.pager only to realize that when I execute
lessseparately, directly on the command line, without Git, it does not exhibit this weird behavior.Yankes commentedon Mar 7, 2025
I made experiment, and run git from cmd, and its look like it work here correctly.
Interesting when I pipe output it fix this behavior:
git commit --amend | cataside of butchering vim, it fix console clearing.
[ps]
another interesting thing is that when using tmux
:pipe-paneto track what is send to terminal I see that git intercept my escape codes and manually clear whole console using\e[Kcodes. Maybe it get confused what$TERMis set now? at least my tmux reportscreen-256color.TomasMalecek commentedon Apr 25, 2025
Inside VS Code's terminal, this issue is not reproducible.
smacdonald-kai commentedon Apr 22, 2026
tl;dr - I am also affected on the latest version
Git For Windows version
Windows version
Options
Other things about my environment
I am working on an inherited laptop that's had tool collisions in the past. This appears not to be one of those, as my colleague with a bog standard install (didn't ask the version number but can get that) has the exact same configuration for all items checked so far, and has the exact same bug.
I've spent about half a day with Copilot digging into this. We have checked a lot of possibilities.
It has a theory that seems reasonable: direct-launched vim is attached to a
pty0but git-launched vim is attached to acons0and that difference is causing the issue.Test to show this data:
$ vim, or, use$ GIT_EDITOR=vim git committo launch vim:!ps -fUsing
Git For Windows bash started via the Windows 11 taskbar Search field, which invokes mintty
Reproducible Example
$ GIT_EDITOR=vim git commitNotes
This does not happen with vim that is invoked from the bash command line; in that case the scrollback is correctly restored.
For the record, OP's report is just about identical to mine.
smacdonald-kai commentedon Apr 22, 2026
I can confirm this
| catdoes in fact cause my reproducible example to no longer reproduce.Here's the
:!ps -ffrom inside git-launched vim; I think the "fixing" part is that cat has apty0as the end of the command line pipeline. vim still hascons0but isn't responsible for restoring the terminal due to being the middle of the command line pipeline (or rather, not the end of the pipeline).Also, just for clarity and assuming OP's test case works, vim isn't really important either. Copilot's theory is that the
t_tiand ort_tesequences are being dropped then the last application is attached to acons0instead of apty0.smacdonald-kai commentedon Apr 22, 2026
OP mentions that the problem exists in 2.47.1.windows.1 but not in 2.24.1.windows.2.
I've downloaded all those releases (61 of them) and will bisect to find the version that introduces the bug. This will take some time as it requires a full uninstall / reinstall cycle for each test, but, ceil(log2(61) + 1) = 6 so at least not too many attempts.
smacdonald-kai commentedon Apr 23, 2026
Bisecting didn't take all that long after all.
(During set up there are 2 initial button clicks to get past Windows User Account Control, then 13 clicks to accept all options as default values. whee)
Summary:
This corresponds to the introduction of the
cons0instead of thepty0(see below for the full log).Bisect log:
smacdonald-kai commentedon Apr 23, 2026
Using the
| catworkaround has other problems.It only works directly from the command-line, or at least, all my attempts to have it work as a git alias, bash alias, or external helper script have failed. Usually this is because cat is also attached to a cons0, near as I can tell.
When it does work direct from the command line, the restored scrollback then also includes all the output from the alternate screen! Most of the time this is nothing, especially for commit message editing, but, sometimes it's very much quite a lot of output.
So the current situation seems to be "live with the bug until it's fixed". :-(
chrisbra commentedon Apr 23, 2026
When it works, can you show the output of
:set t_ti? t_te?in Vim? And then compare if this is different when it doesn't work? I guess those are not set then?17 remaining items
santoslgl01-web commentedon Apr 30, 2026
smacdonald-kai commentedon May 4, 2026
Patch looks good to me, caveat I've never worked in the codebase before.
Because I read over the weekend that some AI(s) is(are) inserting co-author credits into commit messages regardless of whether it is warranted/deserved, I have to ask if "Assisted-by: Claude Opus 4.7 (1M context)" is on purpose or not?
See https://news.ycombinator.com/item?id=47989883 .
Thanks for the patch. I'll test at the next opportunity, whether that's a manual update or just waiting for the next Git for Windows release that includes the patch.
dscho commentedon May 4, 2026
I used it to hunt down promising leads, and to type out the patch under my guidance. So I would say that it is merited to credit Opus with assisting me. The code still is all mine, I instructed the LLM to write it in the way it did.
Cygwin: pty: detect pcon-backed pty for non-Cygwin-spawned children
Cygwin: pty: detect pcon-backed pty for non-Cygwin-spawned children
Cygwin: pty: detect pcon-backed pty for non-Cygwin-spawned children
Cygwin: pty: detect pcon-backed pty for non-Cygwin-spawned children
Cygwin: pty: detect pcon-backed pty for non-Cygwin-spawned children
dscho commentedon Jul 14, 2026
/add relnote bug The long-standing bug where Git Bash's screen was cleared after
git.execalledvim(e.g. to edit a commit message) was fixed.The workflow run was started
Add a release note (bug)
Cygwin: pty: detect pcon-backed pty for non-Cygwin-spawned children (#…
Cygwin: pty: detect pcon-backed pty for non-Cygwin-spawned children
Cygwin: pty: detect pcon-backed pty for non-Cygwin-spawned children