starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-07-08 18:16:28 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Command History on wrong line #9087

New Issue
Closed
opened 2026-01-31 01:45:37 +00:00 by claunia · 23 comments
claunia commented 2026-01-31 01:45:37 +00:00
Owner
Copy Link

Originally created by @nurbles on GitHub (Jun 17, 2020).

Environment

Windows build number: 10.0.19041.329
Windows Terminal version (if applicable): 1.0.1401.0

Any other software? no

Steps to reproduce

Cannot reproduce on demand, but I know it occurred after dragging the window to a new size (number of rows and columns.)

Expected behavior

I was in a Command Prompt, using the Up Arrow to recall my command history.
I expected the recalled commands to appear on the current command line.

Actual behavior

The FIRST command recalled appeared on the current command line, subsequently recalled commands (I pressed Up Arrow more than once) appeared one row above but indented as if after a prompt (though the line above was previously blank.)

FWIW, this is not the first issue I've seen after resizing the window, but almost all of them go away after another resize and do not return if I try to return to the previous size and test for them. So the triggers are difficult to define, sorry. Hopefully this will at least warrant some comments near where this is handled, just in case something is noticed in the code. :-)

Originally created by @nurbles on GitHub (Jun 17, 2020). <!-- 🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨 I ACKNOWLEDGE THE FOLLOWING BEFORE PROCEEDING: 1. If I delete this entire template and go my own path, the core team may close my issue without further explanation or engagement. 2. If I list multiple bugs/concerns in this one issue, the core team may close my issue without further explanation or engagement. 3. If I write an issue that has many duplicates, the core team may close my issue without further explanation or engagement (and without necessarily spending time to find the exact duplicate ID number). 4. If I leave the title incomplete when filing the issue, the core team may close my issue without further explanation or engagement. 5. If I file something completely blank in the body, the core team may close my issue without further explanation or engagement. All good? Then proceed! --> <!-- This bug tracker is monitored by Windows Terminal development team and other technical folks. **Important: When reporting BSODs or security issues, DO NOT attach memory dumps, logs, or traces to Github issues**. Instead, send dumps/traces to secure@microsoft.com, referencing this GitHub issue. If this is an application crash, please also provide a Feedback Hub submission link so we can find your diagnostic data on the backend. Use the category "Apps > Windows Terminal (Preview)" and choose "Share My Feedback" after submission to get the link. Please use this form and describe your issue, concisely but precisely, with as much detail as possible. --> # Environment ```none Windows build number: 10.0.19041.329 Windows Terminal version (if applicable): 1.0.1401.0 Any other software? no ``` # Steps to reproduce <!-- A description of how to trigger this bug. --> Cannot reproduce on demand, but I know it occurred after dragging the window to a new size (number of rows and columns.) # Expected behavior I was in a Command Prompt, using the Up Arrow to recall my command history. I expected the recalled commands to appear on the current command line. <!-- A description of what you're expecting, possibly containing screenshots or reference material. --> # Actual behavior The FIRST command recalled appeared on the current command line, subsequently recalled commands (I pressed Up Arrow more than once) appeared one row above but indented as if after a prompt (though the line above was previously blank.) <!-- What's actually happening? --> FWIW, this is not the first issue I've seen after resizing the window, but almost all of them go away after another resize and do not return if I try to return to the previous size and test for them. So the triggers are difficult to define, sorry. Hopefully this will at least warrant some comments near where this is handled, just in case something is noticed in the code. :-)
claunia commented 2026-01-31 01:45:39 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jun 18, 2020):

Uhg, I see this every so often, and it drives me mad. I was hoping that I had sorted most of this out in #4200, but I definitely missed something. It's a shame that this is so horribly hard to repro.

Gonna toss this in with the rest over at #5800

@zadjii-msft commented on GitHub (Jun 18, 2020): Uhg, I see this every so often, and it drives me mad. I was hoping that I had sorted most of this out in #4200, but I definitely missed something. It's a shame that this is so horribly hard to repro. Gonna toss this in with the rest over at #5800
claunia commented 2026-01-31 01:45:39 +00:00
Author
Owner
Copy Link

@nurbles commented on GitHub (Jun 19, 2020):

FWIW, this just happened to me again and there was no window resizing involved. I have a CMD script that updates the test copies of the software I'm working on that emits 5 lines, does a PAUSE, then emits 17 more. My process is to stop my software, run the script and restart my software (which is actually loaded by a small Windows program that I start from the command line -- nothing of mine is a command line program.) After having down that a few times, enough to cause the window to scroll, the behavior I originally described occurs.

The terminal window HAD been MOVED but not resized at the time I saw this today.

So, I may be able to trigger this on demand, if there is anything I can do to help debug/test this, please let me know.

@nurbles commented on GitHub (Jun 19, 2020): FWIW, this just happened to me again and there was no window resizing involved. I have a CMD script that updates the test copies of the software I'm working on that emits 5 lines, does a PAUSE, then emits 17 more. My process is to stop my software, run the script and restart my software (which is actually loaded by a small Windows program that I start from the command line -- nothing of mine is a command line program.) After having down that a few times, enough to cause the window to scroll, the behavior I originally described occurs. The terminal window HAD been MOVED but not resized at the time I saw this today. So, I may be able to trigger this on demand, if there is anything I can do to help debug/test this, please let me know.
claunia commented 2026-01-31 01:45:39 +00:00
Author
Owner
Copy Link

@mda000 commented on GitHub (Jul 1, 2020):

I do see something very similar to this with no resizing involved. The last couple of lines at the bottom of the terminal can become unavailable for input, and input is overdrawn one or two lines above. It happens randomly, but only rarely--a couple of time a week for me. I have not been able to reproduce the problem.

I'm more than happy to create a minidump or perform other debugging when I see this.

@mda000 commented on GitHub (Jul 1, 2020): I do see something very similar to this with no resizing involved. The last couple of lines at the bottom of the terminal can become unavailable for input, and input is overdrawn one or two lines above. It happens randomly, but only rarely--a couple of time a week for me. I have not been able to reproduce the problem. I'm more than happy to create a minidump or perform other debugging when I see this.
claunia commented 2026-01-31 01:45:40 +00:00
Author
Owner
Copy Link

@nurbles commented on GitHub (Jul 1, 2020):

[using 1.0.1401.0] Not sure this is related but I just rebooted and used a Command Prompt tab to restore three network drives by doing "dir P:" (and Q: and R: if it matters). This, of course, caused the text in the tab to scroll for at least a few pages. I then started to enter another command and pressed ESCAPE to erase it. Instead of being erased, the input cursor jumped to just after my prompt ON THE PREVIOUS LINE. Once this happened, it happened any time I used escape to erase a command. Unfortunately, after restarting the terminal program and opening a new Command Prompt tab I was, of course, unable to get it to happen again.

Are there instructions for capturing anything useful that I can follow if I see this happening again?

@nurbles commented on GitHub (Jul 1, 2020): [using 1.0.1401.0] Not sure this is related but I just rebooted and used a Command Prompt tab to restore three network drives by doing "dir P:" (and Q: and R: if it matters). This, of course, caused the text in the tab to scroll for at least a few pages. I then started to enter another command and pressed ESCAPE to erase it. Instead of being erased, the input cursor jumped to just after my prompt ON THE PREVIOUS LINE. Once this happened, it happened any time I used escape to erase a command. Unfortunately, after restarting the terminal program and opening a new Command Prompt tab I was, of course, unable to get it to happen again. Are there instructions for capturing anything useful that I can follow if I see this happening again?
claunia commented 2026-01-31 01:45:40 +00:00
Author
Owner
Copy Link

@fsigalov commented on GitHub (Aug 7, 2020):

I have a related repaint issue, if I go into history of command, then use left arrow to go back into it and edit it. It does edit, but the repaint is very weird.
image

@fsigalov commented on GitHub (Aug 7, 2020): I have a related repaint issue, if I go into history of command, then use left arrow to go back into it and edit it. It does edit, but the repaint is very weird. ![image](https://user-images.githubusercontent.com/17628060/89595016-4a883580-d808-11ea-8557-3ff0e827aca5.png)
claunia commented 2026-01-31 01:45:40 +00:00
Author
Owner
Copy Link

@jingyu9575 commented on GitHub (Jan 7, 2021):

Hi, I also frequently see this problem. Here are some information I know:

  • On my system when the bug happens, the text always appears 2 lines above. My pwsh prompt is 3 lines (\n 21:07 D:\Desktop WINDOWS-2G64 \n -)

output

  • It is always at the bottom of the terminal window.
  • In this screenshot, there is no scrollbar before the bug occurs. After the bug occurs, if I scroll back to the top, the text will be at the bottom of the terminal, where the prompt - should be. Maybe there are some race conditions about the scrolling?
  • I then tried the mode command which I think affects the scrolling. It seems that repeatly running it triggers this:

LUVUWqlsMn

In this screenshot, the text is at the 3rd line (2 lines lower). If I scroll back to the top, it is exactly where the prompt - should be. It seems to be the reverse problem of the original issue.

@jingyu9575 commented on GitHub (Jan 7, 2021): Hi, I also frequently see this problem. Here are some information I know: * On my system when the bug happens, the text always appears 2 lines above. My pwsh prompt is 3 lines (`\n 21:07 D:\Desktop WINDOWS-2G64 \n -`) ![output](https://user-images.githubusercontent.com/8923139/103897622-cd524b00-512e-11eb-815f-6f7b972352dc.gif) * It is always at the bottom of the terminal window. * In this screenshot, there is no scrollbar before the bug occurs. After the bug occurs, if I scroll back to the top, the text will be at the bottom of the terminal, where the prompt `-` should be. Maybe there are some race conditions about the scrolling? * I then tried the `mode` command which I think affects the scrolling. It seems that repeatly running it triggers this: ![LUVUWqlsMn](https://user-images.githubusercontent.com/8923139/103898842-82393780-5130-11eb-897c-1ba554679cb3.gif) In this screenshot, the text is at the 3rd line (2 lines lower). If I scroll back to the top, it is exactly where the prompt `-` should be. It seems to be the reverse problem of the original issue.
claunia commented 2026-01-31 01:45:41 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jan 7, 2021):

Using mode to set the console window size is going to corrupt your Terminal buffer. You may have noticed that it doesn't actually resize the window 😄

@DHowett commented on GitHub (Jan 7, 2021): Using `mode` to set the console window size is going to corrupt your Terminal buffer. You may have noticed that it doesn't actually resize the window :smile:
claunia commented 2026-01-31 01:45:41 +00:00
Author
Owner
Copy Link

@KirillOsenkov commented on GitHub (Jan 26, 2021):

Once it gets into this state it's pretty corrupted:
CorruptedTerminal

@KirillOsenkov commented on GitHub (Jan 26, 2021): Once it gets into this state it's pretty corrupted: ![CorruptedTerminal](https://user-images.githubusercontent.com/679326/105807766-74bae480-5f5b-11eb-9bee-903c4a735b0b.gif)
claunia commented 2026-01-31 01:45:42 +00:00
Author
Owner
Copy Link

@KirillOsenkov commented on GitHub (Apr 16, 2021):

I just reproduced this again.

This is how it looked like:
image

I typed msbuild /r /m /bl *.sln when the prompt was in the last row, then pressed Tab to complete, and the moment it completed it completed on the line above.

@KirillOsenkov commented on GitHub (Apr 16, 2021): I just reproduced this again. This is how it looked like: ![image](https://user-images.githubusercontent.com/679326/114960983-fc0e4a80-9e1c-11eb-9698-2af9c6a15bf2.png) I typed `msbuild /r /m /bl *.sln` when the prompt was in the last row, then pressed Tab to complete, and the moment it completed it completed on the line above.
claunia commented 2026-01-31 01:45:42 +00:00
Author
Owner
Copy Link

@KirillOsenkov commented on GitHub (Apr 16, 2021):

I just tried this exact sequence again and it didn't repro :(

@KirillOsenkov commented on GitHub (Apr 16, 2021): I just tried this exact sequence again and it didn't repro :(
claunia commented 2026-01-31 01:45:42 +00:00
Author
Owner
Copy Link

@KirillOsenkov commented on GitHub (Apr 16, 2021):

I just noticed that when the caret is dangerously close to the bottom of the screen it sometimes scrolls one line up to bring the caret up further away from the bottom edge, and that scroll happens almost simultaneously with text output.

Is there a lock around that scroll action and the text output? Certainly feels like a race condition where something is not transactional and side effects from scrolling and output are observed before an operation completes.

I'm just speculating of course since I haven't debugged or even looked at the code.

@KirillOsenkov commented on GitHub (Apr 16, 2021): I just noticed that when the caret is dangerously close to the bottom of the screen it sometimes scrolls one line up to bring the caret up further away from the bottom edge, and that scroll happens almost simultaneously with text output. Is there a lock around that scroll action and the text output? Certainly feels like a race condition where something is not transactional and side effects from scrolling and output are observed before an operation completes. I'm just speculating of course since I haven't debugged or even looked at the code.
claunia commented 2026-01-31 01:45:43 +00:00
Author
Owner
Copy Link

@KirillOsenkov commented on GitHub (Apr 16, 2021):

Could we consider bumping the priority on this please? Surprised that corruption and inconsistency of core internal data structures is prioritized as P3. The core data structures should be rock solid and we should do tons of stress testing and fuzzing to catch these issues.

@zadjii-msft @DHowett

@KirillOsenkov commented on GitHub (Apr 16, 2021): Could we consider bumping the priority on this please? Surprised that corruption and inconsistency of core internal data structures is prioritized as P3. The core data structures should be rock solid and we should do tons of stress testing and fuzzing to catch these issues. @zadjii-msft @DHowett
claunia commented 2026-01-31 01:45:44 +00:00
Author
Owner
Copy Link

@KirillOsenkov commented on GitHub (Apr 19, 2021):

Just hit this in the opposite direction with Tab completion, and there was no scrolling involved as the prompt was roughly in the center of the screen:
image

@KirillOsenkov commented on GitHub (Apr 19, 2021): Just hit this in the opposite direction with Tab completion, and there was no scrolling involved as the prompt was roughly in the center of the screen: ![image](https://user-images.githubusercontent.com/679326/115262069-0b291d00-a0e9-11eb-946c-24b978d6a5dc.png)
claunia commented 2026-01-31 01:45:44 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Apr 20, 2021):

Hooplah, a consistent repro from #9897

Steps to reproduce:

  1. Open Terminal (PowerShell)
  2. Push Enter enough times to get to the bottom of the window
  3. Enter line long enough so it will get broken when window is resized horizontally
  4. Move cursor backwards and enter a different character to mark your position
  5. Resize the window horizontally.
  6. When the line gets broken and text scrolls up observe that the cursor is not where it should be

Old console doesn't have this issue.

cmd.exe in Terminal app has a similar issue

I'll add that I remove-module psreadline's first

9897-did-repro-000

@zadjii-msft commented on GitHub (Apr 20, 2021): Hooplah, a consistent repro from #9897 > Steps to reproduce: > > 1. Open Terminal (PowerShell) > 2. Push Enter enough times to get to the bottom of the window > 3. Enter line long enough so it will get broken when window is resized horizontally > 4. Move cursor backwards and enter a different character to mark your position > 5. Resize the window horizontally. > 6. When the line gets broken and text scrolls up observe that the cursor is not where it should be > > Old console doesn't have this issue. > > cmd.exe in Terminal app has a similar issue I'll add that I `remove-module psreadline`'s first ![9897-did-repro-000](https://user-images.githubusercontent.com/18356694/115388261-4850e600-a1a1-11eb-8ba2-888849ece5ab.gif)
claunia commented 2026-01-31 01:45:44 +00:00
Author
Owner
Copy Link

@zzsergant commented on GitHub (May 13, 2021):

Is there any news about this issue or ETA on fix?
I mean, this issue created almost year ago and there are multiple ways to reproduce it. Isn't this a high priority bug?

For me that issue ruining terminal usage experience every day, when it garbage the output and I need to do the resize window workaround and re-run the command again.

@zzsergant commented on GitHub (May 13, 2021): Is there any news about this issue or ETA on fix? I mean, this issue created almost year ago and there are multiple ways to reproduce it. Isn't this a high priority bug? For me that issue ruining terminal usage experience every day, when it garbage the output and I need to do the resize window workaround and re-run the command again.
claunia commented 2026-01-31 01:45:45 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (May 13, 2021):

Nope. We'll make sure to update this thread when there is. In the meantime, might I recommend the Subscribe button?
image
That way you'll be notified of any updates to this thread, without needlessly pinging everyone on this thread ☺️

@zadjii-msft commented on GitHub (May 13, 2021): Nope. We'll make sure to update this thread when there is. In the meantime, might I recommend the Subscribe button? ![image](https://user-images.githubusercontent.com/18356694/91237459-5cbb0c80-e700-11ea-9347-b9b1ec2813b1.png) That way you'll be notified of any updates to this thread, without needlessly pinging everyone on this thread ☺️
claunia commented 2026-01-31 01:45:45 +00:00
Author
Owner
Copy Link

@KirillOsenkov commented on GitHub (May 22, 2021):

Continuing to see weirdness and race conditions:

image

@KirillOsenkov commented on GitHub (May 22, 2021): Continuing to see weirdness and race conditions: ![image](https://user-images.githubusercontent.com/679326/119241355-9ba0b600-bb0a-11eb-8a53-440ccc7a7119.png)
claunia commented 2026-01-31 01:45:45 +00:00
Author
Owner
Copy Link

@Chaython commented on GitHub (May 29, 2021):

Don't want to hijack, but is there any way to have session/history be persistent?
Like when I restarted windows terminal, it is a clean start, I want my last session back...
Is there anyway to save commands? Like FISH remembers all past input and dynamically recommends scripts as you type.

@Chaython commented on GitHub (May 29, 2021): Don't want to hijack, but is there any way to have session/history be persistent? Like when I restarted windows terminal, it is a clean start, I want my last session back... Is there anyway to save commands? Like FISH remembers all past input and dynamically recommends scripts as you type.
claunia commented 2026-01-31 01:45:45 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Aug 19, 2021):

terminal vs pty. Doesn't seem like #5368 affects this
image

though, same thing in just conhost:

image

OH BUT INTERESTING.

If you set conhost's buffer to be the same size as the viewport, then it'll repro exactly the same. Furthermore, same will happen with conhost+cmd.exe+buffer.size=viewport.size
gh-6546-000

@zadjii-msft commented on GitHub (Aug 19, 2021): terminal vs pty. Doesn't seem like #5368 affects this ![image](https://user-images.githubusercontent.com/18356694/130087064-b153b45f-529d-414a-aa9a-a60b2c631339.png) though, same thing in just conhost: ![image](https://user-images.githubusercontent.com/18356694/130087767-92467da5-e600-4071-b39d-b86c9c608548.png) OH BUT INTERESTING. If you set conhost's buffer to be the same size as the viewport, then it'll repro exactly the same. Furthermore, same will happen with conhost+cmd.exe+buffer.size=viewport.size ![gh-6546-000](https://user-images.githubusercontent.com/18356694/130088564-2c91db6c-7607-4d2d-9d4d-053fc6d5359f.gif)
claunia commented 2026-01-31 01:45:45 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Aug 19, 2021):

Okay I'm getting too into the weeds here I think. These feel like issues that'll just go away with #8000. There's weirdness going on where it seems like the TextBuffer circled once to leave a space for this line where the cursor should be, but the cursor is actually at the start of the prompt (and the prompt isn't in the buffer during the resize). So it ends up redrawing itself where it was, which is now a blank line. But that blank line should have never existed!

@zadjii-msft commented on GitHub (Aug 19, 2021): Okay I'm getting too into the weeds here I think. These feel like issues that'll just go away with #8000. There's weirdness going on where it seems like the TextBuffer circled once to leave a space for this line where the cursor should be, but the cursor is actually at the start of the prompt (and the prompt isn't in the buffer during the resize). So it ends up redrawing itself where it _was_, which is now a blank line. But that blank line should have never existed!
claunia commented 2026-01-31 01:45:46 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Aug 19, 2021):

      // There is a special case here. If the row has a "wrap"
        // flag on it, but the right isn't equal to the width (one
        // index past the final valid index in the row) then there
        // were a bunch trailing of spaces in the row.
        // (But the measuring functions for each row Left/Right do
        // not count spaces as "displayable" so they're not
        // included.)
        // As such, adjust the "right" to be the width of the row
        // to capture all these spaces
        if (row.WasWrapForced())

We're hitting the case where the last row of the buffer thinks it was wrapped, so we fill all the spaces into the new buffer. But that's not really the case! The commandline was hidden, so that line shouldn't be marked as wrapped!

EDIT:

But, this makes me think that this particular repro isn't the same root cause as the other bugs. This is just the Commandline/cooked read failing to unmark a line as wrapped in one very particular scenario. This is far too specific to be relevant to the plethora of other examples here (despite not having consistent repros for those).

@zadjii-msft commented on GitHub (Aug 19, 2021): ``` // There is a special case here. If the row has a "wrap" // flag on it, but the right isn't equal to the width (one // index past the final valid index in the row) then there // were a bunch trailing of spaces in the row. // (But the measuring functions for each row Left/Right do // not count spaces as "displayable" so they're not // included.) // As such, adjust the "right" to be the width of the row // to capture all these spaces if (row.WasWrapForced()) ``` We're hitting the case where the last row of the buffer thinks it was wrapped, so we fill all the spaces into the new buffer. But that's not _really_ the case! The commandline was hidden, so that line _shouldn't_ be marked as wrapped! EDIT: But, this makes me think that this particular repro isn't the same root cause as the other bugs. This is just the `Commandline`/cooked read failing to unmark a line as wrapped in one very particular scenario. This is far too specific to be relevant to the plethora of other examples here (despite not having consistent repros for those).
claunia commented 2026-01-31 01:45:46 +00:00
Author
Owner
Copy Link

@alrz commented on GitHub (Jul 8, 2024):

This issue is kind of came back. I'm using preview 1.21.1772.0, just using a curl with a long url and making edits in the middle and hitting enter doesn't exactly send the same command as seen in history with the up key.

image

@alrz commented on GitHub (Jul 8, 2024): This issue is kind of came back. I'm using preview 1.21.1772.0, just using a curl with a long url and making edits in the middle and hitting enter doesn't exactly send the same command as seen in history with the up key. ![image](https://github.com/microsoft/terminal/assets/3105979/f30fda0d-cdca-404a-a5d9-8f6f38437524)
claunia commented 2026-01-31 01:45:46 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Jul 8, 2024):

@alrz Could you open a new issue for this? It'd be especially nice if you had a repro case for us.

@lhecker commented on GitHub (Jul 8, 2024): @alrz Could you open a new issue for this? It'd be especially nice if you had a repro case for us.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Area-Output In-PR Issue-Bug Needs-Tag-Fix Priority-2 Product-Terminal
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#9087
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?