git bash for windows in terminal does not break lines correctly

[RedX2501]

Environment

Platform ServicePack Version      VersionString
-------- ----------- -------      -------------
 Win32NT             10.0.18363.0 Microsoft Windows NT 10.0.18363.0

Windows Terminal Preview
Version: 1.7.572.0

Setting for git bash:

            {
                "name": "git bash",
                "commandline": "%PROGRAMFILES%/git/usr/bin/bash.exe -i -l",
                "icon": "%PROGRAMFILES%/Git/mingw64/share/git/git-for-windows.ico",
                "startingDirectory" : "%USERPROFILE%"
            },

Steps to reproduce

1. Open a terminal window with git for windows bash
2. Do a rebase operation

Expected behavior

Line breaks start at the beginning of the next line.

Actual behavior

git rod is an alias for git rebase --autostash -i origin/develop

$git rod
error: could not apply 6b04f92e... DuplicateInput now supports generating code for arrays for the VfcTypeImplementation
                                                                                                                                  Resolve all conflicts manually, mark them as resolved with
                                                                                                                                                                                            "git add/rm <conflicted_files>", then run "git rebase --continue".
                                                                                                                                                                                                                                                              You can instead skip this commit: run "git rebase --skip".
                                           To abort and get back to the state before "git rebase", run "git rebase --abort".
                                                                                                                            Recorded preimage for 'src/App/Changelog.md'
                                                                                                                                                                        Could not apply 6b04f92e... DuplicateInput now supports generating code for arrays for the VfcTypeImplementation
                      Auto-merging src/App/Tests/Silt.Plugin.SimpleTransformersGeneratorTests/GeneratorTests/DuplicateInputTransformerTests.cs
                                                                                                                                              Auto-merging src/App/Plugins/Silt.Plugin.SimpleTransformersGenerator/GeneratorStrategy/DuplicateInputTransformer.cs
                                                                                                                                                                                                                                                                 Auto-merging src/App/Changelog.md
                     CONFLICT (content): Merge conflict in src/App/Changelog.md

It seems that only the console without \r is not returning the operator to the beginnig of the line.

Not sure if there is a setting I need to configure for this to work.

[zadjii-msft]

@DHowett can you sanity check what's going on here? I forget how mingw works some times. We've had this one and #9312 in the course of a single week, and I don't think we changed anything about our console mode handling.

[RedX2501]

Forgot to mention I saw this on preview. I have not checked on the "official" version yet. I have added the version number to the post above.

[RedX2501]

I also see this in the official version

Windows Terminal
Version: 1.6.10571.0

$git rebase -i develop
Successfully rebased and updated refs/heads/testing.
                                                    myPc /c/data/sw testing

[RedX2501]

Today this led to a buffer overrun exception:

[zadjii-msft]

Well that's super weird. I don't think that's necessarily caused by the same thing that's causing the \r to get dropped here. We've seen that before in #7763, but that had more to do with resizing the buffer with DBCS characters in it, and presumably that's not happening in this case.

If that happens again, can you use task manager to capture a dump file of Terminal when that dialog pops up?

[ffes]

I see this behavior with every git commit I do. Other git subcommands seem to work for me, though I haven't used rebase recently. Never ran into the buffer overrun, mentioned above.

FYI:
Windows Terminal Preview Version: 1.9.1523.0
git version 2.31.1.windows.1

[KalleOlaviNiemitalo]

Does stty onlcr help?

[KalleOlaviNiemitalo]

Regarding the error message:

The system detected an overrun of a stack-based buffer in the application. This overrun could potentially allow a malicious user to gain control of this application.

As described in STATUS_STACK_BUFFER_OVERRUN doesn’t mean that there was a stack buffer overrun, the same exception code is nowadays used for other purposes too. I don't know whether Windows nowadays bothers to check the fast-fail code before it pops up the message box with this wording.

[poke]

To add what we know from the other issue #10152, can you check your TERM environment variable when you experience the formatting issue or even the crash? In my situation, it depends on what value it has. Apparently, Git Bash defaults to xterm, and I personally hit these issues with the value msys when using PowerShell.

Terminal definitely behaves different here from other console emulators like the default conhost, mintty or ConEmu.

[ffes]

In my case in Windows Terminal Preview v1.11.2421.0:

$ echo $TERM
xterm-256color

When I run "Git Bash" from the Start Menu (which uses mintty):

$ echo $TERM
xterm

[RedX2501]

Both are xterm-256color for me.

[KalleOlaviNiemitalo]

How about the stty command?

On Linux, Git would output just a LF, the Linux tty driver would convert that to CR LF, and the terminal would move the cursor to the start of the line on CR and then to the next line on LF. This behaviour of the terminal driver can be enabled or disabled with the ONLCR flag in the tcsetattr function, or with the stty program.

On Windows, the console host does not convert LF to CR LF, so I assume this is instead done by some emulation layer in the Git for Windows package. If the emulated ONLCR flag has become turned off (e.g. because an editor such as vi turned it off and then was killed before it was able to turn the flag back on), that could cause the symptom described here. In this situation, stty onlcr or stty sane would turn the flag back on and make the output look OK again.

[j4james]

FYI, on Windows this behaviour is controlled by the DISABLE_NEWLINE_AUTO_RETURN output mode. So maybe someone is setting that mode and not restoring it on exit. If that's the problem, it could potentially be fixed by #4954.

[KalleOlaviNiemitalo]

I was mislead by MicrosoftDocs/Console-Docs#132.

Anyway, if I run stty -onlcr in Git Bash on Windows Terminal Preview 1.11.2421.0, and then run git --help | cat, it produces the ugly output. If I then start cmd in the same pane and run type to display a file that uses only LFs as line terminators, each line starts at the left margin. After that, if I exit from cmd to Git Bash and run git --help | cat again, the output is still ugly. This makes me believe the ONLCR flag is being emulated by MSYS (which is used by stty and cat but not by git) rather than mapped to DISABLE_NEWLINE_AUTO_RETURN.

[carenas]

So maybe someone is setting that mode and not restoring it on exit.

Correct; vim takes an output console from git with ENABLE_PROCESSED_OUTPUT | ENABLE_WRAP_AT_EOL_OUTPUT adds DISABLE_NEWLINE_AUTO_RETURN | ENABLE_VIRTUAL_TERMINAL_PROCESSING and returns it dirty (even if it doesn't crash AFAIK).

adding functionality in Git for Windows that resets the terminal after vi returns workarounds the issue and will be present in a future release

[carenas]

FWIW the workaround from git to reset the terminal settings after vi is invoked has been merged and is released as part of the last Git for Windows prerelease:

https://github.com/git-for-windows/git/releases/tag/v2.34.0-rc0.windows.1

This should avoid the most egregious cases until a final solution to keep them consistent is found

[ghost]

Can some help, gitbash terminal break in middle when i clear the old log then the new log start in the bottom.

[carenas]

FYI, I made a fatal mistake on the way this workaround was implemented originally within git and therefore the code had to be reverted for 2.34.1, but luckily the Git for Windows maintainer picked it up and might still work when using 2.34.1.windows.1 (or later).

If you are having problems, make sure to NOT have any of the environment variables used to override the editor defined in your environment (ex: VISUAL, EDITOR, GIT_EDITOR, GIT_SEQUENCE_EDITOR) AND NOT have a core.editor setting, OR that they are set exactly to 'vi' or 'vim' ('vim.exe' or '/usr/bin/vi' will not activate the workaround and still corrupt your terminal).

[C0DK]

I am experiencing something similar with WSL 2.0 and Ubuntu in the Windows Terminal, with git version 2.25.1 - yet that shouldn't be git for windows; but just plain old git:

It happens after having run an interactive rebase (which I assume is also when vim is opened.). I've set the editor to vim, (as per @carenas suggestion) rather than the full vim-path, yet it didn't do anything better or worse.

Is this related to the problem? and do you brilliant people know of any quick fix?

[carenas]

Is this related to the problem? and do you brilliant people know of any quick fix?

the mentioned workaround only applies to git for windows (requires code in git that is not part of the regular codebase yet).

it definitely looks like the same problem, and as documented in #10152 another workaround that doesn't require code changes is to set TERM to something else than xterm*; ex:

> export TERM=vt100

it is important also to note that running reset after vi is invoked should also fix the terminal, as well as fixing your rbim command/alias so it doesn't attempt to run vi in a non terminal, if that is possible (expect might help there)

[C0DK]

I never tested vt100, @carenas - i did now.

vt100 didn't do much more than removing my beautiful colors. Reset is currently my preferred trick. but might just postfix the reset command to my alias.

[carenas]

vt100 didn't do much more than removing my beautiful colors

will see if I can try again to get my fix merged into git upstream (hopefully for 2.37), which then could be maybe backported to your version; but considering your version is old and probably out of maintenance it might be worth upgrading it regardless.

[zadjii-msft]

@carenas You know if this was ever fixed upstream? Or, if it wasn't, is there an upstream issue we could point this thread at?

[carenas]

You know if this was ever fixed upstream?

AFAIK the "fix" implemented in git for windows[1] is only a workaround to the effects of this bug.

[1] git-for-windows/git@db157fb

[othmanalikhan]

I'm experiencing a similar situation where Git Bash for Windows messed up line wrapping (and consequently doesn't break lines properly). To replicate:

1. Open Git Bash session in Windows Terminal
2. Just press up-arrow to load a command from history
3. Move the cursor to the start of the line of the command that appears, and that becomes rather wonky (especially for long commands that should be line broken).

See this image to illustrate:

I should add that changing the $TERM variable can sometimes fix it but sometimes makes things even more wonkier.

EDIT: Nevermind, found my issue and it isn't caused by Windows Terminal... I had a function in my .bashrc that was overriding the $PS1 variable incorrectly. Fixed it and confirm everything is working. This issue was plaguing me for about a year now... But no longer.

[carlos-zamora]

Hi all! There's been a lot of changes in this space recently, and we're hoping it gets better with 1.18 which is slated to come out in a few months.

[lost-scripts]

FWIW, in my case what triggers the issue is this line...

export MSYS=winsymlinks:nativestrict # Allow symlink creation on Windows perpetually

...that I added at some point to my .bashrc file. IOW, I've just discovered that if I comment that line and relaunch the terminal I get the expected output:

Whereas as soon I uncomment it and relaunch the terminal, I start getting this again:

Curious thing is for some reason the behavior only changes after the second interaction once activated/deactivated the culprit line (no matter if I relaunch or reload), as can be seen in the first capture. Well, I hope it somehow helps, or give some clue at least, on figuring out what could be going on cause it's certainly annoying... and what if (as happen to be the case) you need such or other similar settings to be active? 🙄 Cheers.

---

git version 2.45.1.windows.1
GNU bash, version 5.2.26(1)-release (x86_64-pc-msys)

[DHowett]

If toggling an msys feature on and off changes the behaviour of msys, it may be worth filing a bug on msys! I'm not sure how that would impact Terminal, but it is a really great data point. Thanks!

FWIW: it looks like that terminal is mintty, so we might not even be involved here (since msys applications use a special connection they have with mintty to skip all the Windows Console code)