Repository navigation
git bash for windows in terminal does not break lines correctly #9359
Description
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
- Open a terminal window with git for windows bash
- 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.
Activity
zadjii-msft commentedon Mar 3, 2021
Dustin L. Howett (@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 commentedon Mar 4, 2021
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 commentedon Mar 4, 2021
I also see this in the official version
RedX2501 commentedon Mar 5, 2021
Today this led to a buffer overrun exception:
zadjii-msft commentedon Mar 5, 2021
Well that's super weird. I don't think that's necessarily caused by the same thing that's causing the
\rto 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 commentedon Jul 9, 2021
I see this behavior with every
git commitI do. Other git subcommands seem to work for me, though I haven't usedrebaserecently. 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 commentedon Jul 10, 2021
Does
stty onlcrhelp?KalleOlaviNiemitalo commentedon Jul 10, 2021
Regarding the error message:
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.
30 remaining items
C0DK commentedon Feb 18, 2022
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 Carlo Marcelo Arenas Belón (@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 commentedon Feb 18, 2022
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:
it is important also to note that running
resetafter 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 (expectmight help there)C0DK commentedon May 16, 2022
I never tested vt100, Carlo Marcelo Arenas Belón (@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
resetcommand to my alias.carenas commentedon May 16, 2022
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 commentedon Nov 8, 2022
Carlo Marcelo Arenas Belón (@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 commentedon Nov 8, 2022
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 commentedon Feb 11, 2023
I'm experiencing a similar situation where Git Bash for Windows messed up line wrapping (and consequently doesn't break lines properly). To replicate:
See this image to illustrate:
I should add that changing the
$TERMvariable 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 commentedon Feb 22, 2023
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 commentedon Jul 2, 2024
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 commentedon Jul 2, 2024
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)
editor: save and reset terminal after calling EDITOR