AI Textconv filter misconfiguration on Windows leads to silent corruption of diff output (ongoing investigation)

AI Textconv filter misconfiguration on Windows leads to silent corruption of diff output (ongoing investigation)

[Skybuck Flying]

Dear Git maintainers,

I am writing to report a highly confusing and time‑consuming issue that I have encountered while using Git on Windows. The problem involves Git's textconv mechanism, the bundled sed, and a seemingly harmless configuration intended to remove carriage returns (CR) before displaying diffs. The issue is still under investigation, and I have not yet applied a definitive solution, but I believe it is worth reporting because it can cause massive confusion and wasted time for other users.

Background

I am working on a private branch of a Go project on Windows 10 (Git version 2.x, installed at C:\Tools\Git). I noticed that git diff between two commits (e.g., 429c244..70f57a8) showed added lines containing corrupt identifiers. For example:

- compareCache appeared as compaeCache
- return appeared as eturn
- from appeared as fom
- var appeared as va
- for appeared as fo
- cacheReader appeared as cacheReade
- CompareAndSwap appeared as CompaeAndSwap

The repository itself was clean. Extracting the actual file content from the commit with git show <commit>:net/sync_cache_reader.go correctly showed the proper spelling (e.g., compareCache). Running git diff --no-textconv produced the correct diff, proving that the corruption was introduced by a textconv filter.

Configuration

I had configured a textconv filter to normalize line endings before displaying diffs. Importantly, this configuration was not manually created by me; it was suggested by an AI assistant (specifically GitHub Copilot) while I was trying to solve a different problem with line endings. The AI recommended adding:

Global .gitconfig:
diff.lfclean.textconv=sed -e s/\r//

.gitattributes (in the repository):
*.go diff=lfclean

The intention was to remove carriage return (CR) characters from files before diffing, to avoid seeing ^M in the output.

This is a beautiful example of how AI can create confusion – the advice seemed perfectly reasonable but led to silent corruption of diffs, wasting many hours of debugging.

Observed Behavior

- git diff (with the filter active) shows corrupted output (missing the letter 'r').
- git diff --no-textconv shows correct output.
- git show <commit>:<file> shows correct content.
- git status shows no modifications; the working tree is clean.

Thus, the repository is not corrupt; the diff presentation is being altered.

Initial Diagnosis

I suspected that sed was misinterpreting the \r escape sequence. I found that Git for Windows bundles its own sed (at C:\Tools\Git\usr\bin\sed.exe), which is used even when sed is not in the system %PATH%. Running the command directly:

echo compareCache | C:\Tools\Git\usr\bin\sed.exe -e s/\r//

outputs:

compaeCache

So the command does strip the literal character 'r' instead of carriage returns. The likely reason is that the backslash before r is not preserved through the shell argument parsing on Windows; effectively, the expression becomes s/r//, which deletes all 'r' characters.

Impact

- Diff output becomes unreliable; users may falsely suspect repository corruption.
- Debugging is extremely time‑consuming. In my case, several hours were wasted, involving multiple tools and even AI assistants, before the root cause was identified.
- The problem is silent – no error messages are shown, making it hard to detect.
- This case also highlights a risk of relying on AI‑generated Git configurations without fully understanding the platform‑specific pitfalls.

Current Status

I have not yet decided on a permanent fix. I am considering removing the filter entirely, replacing it with a safer command (e.g., tr -d \r), or using --no-textconv when needed. However, I wanted to report this to the mailing list to:

1. Warn other Windows users about this pitfall, especially when taking advice from AI assistants.
2. Suggest possible improvements to Git to prevent such confusion in the future.

Suggested Improvements

- Documentation: Add a warning to gitattributes and git-config about using backslash escapes in textconv commands on Windows. Provide safe examples for removing CR, such as:
  diff.lfclean.textconv=tr -d \r
  or
  diff.lfclean.textconv=dos2unix

- Built-in filter: Consider offering a built-in textconv filter for line-ending normalization, e.g., diff.lfclean.textconv=git-crlf-remove, which would robustly handle CR stripping without relying on external tools or escaping pitfalls.

- Debugging aid: Add a flag like --debug-textconv that logs the exact command being executed for a textconv filter. This would help users see that their configured command may not be what they expect.

- Warning for suspicious patterns: On Windows, Git could detect textconv commands containing \r and emit a warning that this may be misinterpreted, suggesting safer alternatives.

Workaround for Affected Users

Remove the faulty filter:
git config --global --unset diff.lfclean.textconv
and delete or comment out the line in .gitattributes.

Alternatively, use git diff --no-textconv to bypass the filter when needed.

Conclusion

This issue is a result of a common misconfiguration combined with the quirks of Windows command parsing and the bundled sed. While Git itself is not at fault, better documentation and maybe a built-in solution would greatly improve the user experience for Windows developers. Additionally, this incident serves as a cautionary tale about relying on AI‑generated advice for system‑level configurations without understanding the underlying platform specifics.

I am happy to assist with testing any proposed documentation changes or additional debugging features. Thank you for your consideration.

Yours sincerely,
  Skybuck Flying (skybuck2000@hotmail.com)

Personal note: I BLAME LINUX FOR NOT FOLLOWING THE CARRIAGE RETURN NEW LINE CONVENTION. I ALSO BLAME/DISLIKE WINDOWS 11 ENVIRONMENT DIALOG PATH 2047 LIMIT WHICH MIGHT FURTHER CONFUSE THINGS, RE-ORDERING OF PATHS ALSO OCCURED BY AI TO TRY AND SOLVE THIS PATH DIALOG GUI LIMITATION ISSUE, LONGER PATH WAS SET DIRECTLY INTO THE REGISTRY.

Re: AI Textconv filter misconfiguration on Windows leads to silent corruption of diff output (ongoing investigation)

[Skybuck Flying]

I confronted Co-Pilot with it, according to Co-Pilot you will like this shorter report better, more to the point:

Hi,

I encountered an issue on Windows where a textconv filter intended to strip
carriage returns ends up corrupting diff output by removing literal 'r'
characters.

Configuration:

    [diff "lfclean"]
        textconv = sed -e s/\r//
    *.go diff=lfclean

Environment:
- Windows 10
- Git for Windows (2.x)
- sed from Git for Windows: usr/bin/sed.exe

Problem:
Running `git diff` on Go source files shows corrupted identifiers:
    compareCache → compaeCache
    return → eturn
    for → fo
    cacheReader → cacheReade
etc.

The repository content is correct:
- `git diff --no-textconv` shows correct diffs.
- `git show <commit>:<file>` shows correct content.

Reproduction outside Git:

    echo compareCache | C:\Tools\Git\usr\bin\sed.exe -e s/\r//

Output:

    compaeCache

So sed removes literal 'r' instead of carriage returns. It appears that on
Windows, the backslash in `\r` is not preserved through MSYS argument parsing,
effectively turning the expression into `s/r//`.

Impact:
- Diff output becomes misleading/corrupted.
- No warning is emitted.
- The issue is silent and difficult to diagnose.

Suggestion:
- Consider documenting that sed-based textconv filters using backslash escapes
  are unsafe on Windows.
- Possibly warn when textconv commands contain `\r` on Windows.
- A built-in CR-stripping textconv filter would avoid these pitfalls.

Thanks,
  Skybuck Flying

Re: AI Textconv filter misconfiguration on Windows leads to silent corruption of diff output (ongoing investigation)

[Skybuck Flying]

Perfectly confusing, I will just continue spamming until the fucking AI figures out, I am not wasting one single brain cell in this mess:

To: git@vger.kernel.org
Subject: Windows: textconv pipeline corrupts diff output (sed not at fault)

Dear Git maintainers,

I would like to report an extremely confusing and time‑consuming issue involving
Git’s textconv mechanism on Windows. The problem causes *silent corruption* of
diff output, leading to hours of wasted debugging and false suspicion of
repository damage.

This is not a sed bug, not a shell bug, and not a user error. It is a problem
inside Git’s textconv pipeline on Windows.

Environment:
- Windows 10
- Git for Windows (2.x)
- sed.exe from Git for Windows (usr/bin/sed.exe)
- textconv filter configured via .gitattributes

Symptoms:
When diffing Go source files, Git shows corrupted identifiers such as:

    compareCache  → compaeCache
    return        → eturn
    for           → fo
    cacheReader   → cacheReade

Important:
- The repository content is correct.
- `git diff --no-textconv` shows correct output.
- `git show <commit>:<file>` shows correct content.
- The working tree is clean.
- Running sed manually on Windows behaves correctly and does NOT corrupt text.

In other words: the corruption happens *only* inside Git’s textconv execution
path.

Root cause (confirmed):
Git’s textconv pipeline on Windows is altering the output of the filter in a way
that removes characters from the diff. The corruption cannot be reproduced by
running sed.exe directly from cmd.exe or PowerShell. It only occurs when Git
invokes the filter.

This makes the issue extremely difficult to diagnose, because:
- The filter command appears harmless.
- The external tool behaves correctly when tested manually.
- Git emits no warnings.
- The corruption is silent and misleading.

Impact:
This problem is incredibly frustrating for users. It creates the illusion of
repository corruption, breaks trust in diff output, and wastes hours of
debugging time. In my case, I spent a long time chasing phantom bugs in Go code
before discovering that Git itself was altering the diff output.

Request:
I would like to ask the Git for Windows maintainers to investigate the
textconv execution path, specifically how filter output is captured and passed
to the diff machinery. Something in this pipeline is modifying the text in a
way that does not occur when running the same command outside Git.

Even a small diagnostic improvement would help enormously:
- A flag like `--debug-textconv` to show the exact bytes Git receives from the
  filter.
- A warning when textconv output differs in size from the original file.
- Documentation clarifying platform‑specific pitfalls for textconv on Windows.

This issue is subtle, silent, and extremely irritating to debug. I hope this
report helps prevent other Windows users from losing hours to the same problem.

Thank you for your time.

Sincerely,
Skybuck Flying

FUCK YOU ALL TO HELL.

Re: AI Textconv filter misconfiguration on Windows leads to silent corruption of diff output (ongoing investigation)

[Skybuck Flying]

Faulting application name: WindowsTerminal.exe, version: 1.24.2605.12001, time stamp: 0x6a03a6ca
Faulting module name: Microsoft.Terminal.Control.dll, version: 1.24.2605.12001, time stamp: 0x6a03a3a2
Exception code: 0xc0000005
Fault offset: 0x000000000002c924
Faulting process id: 0x0x5E3C
Faulting application start time: 0x0x1DD2916AA80F175
Faulting application path: C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.24.11321.0_x64__8wekyb3d8bbwe\WindowsTerminal.exe
Faulting module path: C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.24.11321.0_x64__8wekyb3d8bbwe\Microsoft.Terminal.Control.dll
Report Id: cd357657-4241-4a05-95d5-54ad0292fa24
Faulting package full name: Microsoft.WindowsTerminal_1.24.11321.0_x64__8wekyb3d8bbwe
Faulting package-relative application ID: App

As if this day wasn't bad enough yet, windows terminal also crashes, trying to copy & paste the command line used to actually fix git.

Many copy & pastes were hurt this day. uBlock origin also started fucking around with copy & paste functionality, blocking it.

Hit the big logo which looks like a power icon to turn it off... or read this horrible dev issue thread, which contains some more manuals how to add a by-pass/circumment/exclude filter for deepseek website:

https://github.com/vitelabs/go-vite/issues/656

It's good to read this anyway, to see how SHITTY your git actually is, it orginally started with trying to apply your git diff output via the patch feature which miserably failed !

None the less a branch was created anyway, with commits, which is a more proper way to do it...

I can't believe you linux faggots used patches all this time, it has rarely worked for me, your parsers are total shit. You need to start using AI and first SPEC THE HELL OUT OF IT by using every AI in the book: deepseek v4, gemini 3.6, grok 4.x, chatgpt 5.x, meta.ai spark 1.1 

Only then will your software improve.

Anyway, thankfully the entire browser didn't crash yet, I should be able to at least copy & paste the instruction out of there:

git config --global diff.lfclean.textconv "sed -e s/\\r//"


TO ALL SOFTWARE DEVELOPERS AND CODE FAG BUNNIES ALL OVER THE WORLD:

TEST YOUR COPY & PASTE FUNCTIONALITY 1000X BETTER

TEST YOUR SELECT FUNCTIONALITY 1000X BETTER

TEST YOUR DRAG & DROP FUNCTIONALITY 1000X BETTER

I RUN INTO THESE KINDS OF MALFUNCTIONS

ALL

THE

TIME.

BLOODY

FUCKING

ANNOYING

BYE

FOR

NOW

I 

HOPE

I 

GET

BANNED

SO 

I

CAN

PUT

SHITTY

LINUX

SOFTWARE

TO

REST

MAYBE

I MAKE A NICE PARODY USING:

"SOUND OF SILENCE" BY THAT WELL KNOWN GANG OF MUSIC ARTISTS

TUT TUT TUT TUT TUT TUTUT TUTUT TUTUT

OH YEAH I REMEMBER NOW:


"SHOUT !"

"SHOUT !"

"THROW LINUX OUT !"

"THROW THAT GARBAGE OF THE PLANET"

"COME ON"

"JUST THROW IT OUT"

"COME ON !"

"AND IF I"

"COULD JUST NOT HAVE TO DEAL WITH LINUX"

"I COULD JUST CODE FINE"

"AND I WOULDN'T BE WASTING MY TIME !"

"I'D BE CODING FINE !"

"AND NOT BE WASTING MY TIME"

"SHOUT ! SHOUT ! THROW GIT AND LINUX OUT !"

"COME ON !"

"GET RID OF THAT GARBAGE !"

"COME ON !"

BYE FOR NOW,
  SKYBUCK.

P.S.: DON'T DEVELOP YOUR OWN OS, IF YOU CAN'T FOLLOW SOME FUCKING SIMPLY STANDARDS LIKE CARRIAGE RETURN AND NEWLINE

BY FUCKERS.

Re: AI Textconv filter misconfiguration on Windows leads to silent corruption of diff output (ongoing investigation)

[Skybuck Flying]

(I am not yet done with you mtf-ers):

I feed the crash log into Co-Pilot/AI, it knows about it:

The short answer: **your crash codes indicate an *access‑violation* inside Windows Terminal’s rendering/control DLL**, and the specific signature you posted matches a **known Windows Terminal bug** that occurs during **tab drag‑merge operations**, often when scrollback buffers are large.

---

## 🧩 What the codes mean (direct interpretation)

- **Faulting application:** WindowsTerminal.exe  
- **Faulting module:** Microsoft.Terminal.Control.dll  
- **Exception code:** **0xc0000005** → **Access violation** (invalid memory read/write)   [cloudspress.com](https://www.cloudspress.com/how-to-fix-error-code-0xc0000005-on-windows-11/)  
- **Fault offset:** 0x2C924 → The exact instruction inside the DLL where the crash occurred  
- **Process ID / start time:** Just identifiers; not diagnostic

**0xc0000005** specifically means the program tried to **read or write memory it shouldn’t**, typically due to:

- Null pointer dereference  
- Use‑after‑free  
- Corrupted internal state  
- Memory pressure causing unexpected behavior  
- A bug in the module (in this case, Microsoft.Terminal.Control.dll)

---

## 🧠 Why this specific crash is happening

Your crash signature **exactly matches** a documented Windows Terminal issue:

- **Crash during tab drag‑merge**  
- **Faulting module:** Microsoft.Terminal.Control.dll  
- **Exception:** 0xc0000005  
- **Offset:** same region (0x2Cxxx)  
- **Version:** 1.24.2605.12001  

This is confirmed in the Windows Terminal GitHub issue tracker:  
- Issue #20406 describes **intermittent crashes when merging tabs**, with the **same version and same DLL**.   [Github](https://github.com/microsoft/terminal/issues/20406)  
- Issue #19383 shows similar crashes in earlier versions, also during tab merge operations.   [Github](https://github.com/microsoft/terminal/issues/19383)  

The maintainers note:

- The crash occurs **inside the control DLL**, not user code.  
- It is triggered by **dragging a tab from one window into another**.  
- Large scrollback buffers or memory growth (RADAR_PRE_LEAK_64) increase the likelihood.  
- All Terminal windows die because they share a single process.

This is **not caused by your system**, drivers, or RAM.  
It is a **bug in Windows Terminal 1.24**.

---

## 🔍 What 0xc0000005 means in general

Windows uses 0xc0000005 for **any illegal memory access**:

- **0** → invalid read  
- **1** → invalid write  
- **8** → invalid code execution  
  [cloudspress.com](https://www.cloudspress.com/how-to-fix-error-code-0xc0000005-on-windows-11/)

In your case, the GitHub issues strongly indicate a **null pointer dereference** inside the tab‑merge logic.

---

## 🛠 What you can do

### 1. Avoid tab drag‑merge for now  
This is the direct trigger in the known bug reports.

### 2. Reduce scrollback size  
Large scrollback buffers increase memory pressure and crash likelihood.

### 3. Update Windows Terminal  
Check for a newer version than **1.24.2605.12001**.  
The bug is known and under triage.

### 4. If you want deeper debugging  
You can capture a dump and inspect with WinDbg:

- `!analyze -v`  
- Check the call stack around the fault offset  
- Look for pointer dereferences inside Microsoft.Terminal.Control.dll

But based on the GitHub reports, you will likely see the same signature as others.

---

## 🧭 If you want, I can help you:

- Analyze your crash dump  
- Explain how to use WinDbg step‑by‑step  
- Check whether your settings.json might also be contributing

Just pick one.
"


Me:
"
Has a new version of terminal window been released which solves this bug ?
"

**Yes — a newer Windows Terminal build *has* been released that specifically fixes the tab‑drag crash you’re experiencing.**  
The fix landed in **Windows Terminal 1.24.11911.0**, released mid‑July 2026, and confirmed in multiple sources as addressing the drag‑merge crash you hit.   [NT Compatible](https://www.ntcompatible.com/story/windows-terminal-124-and-125-update-released-bug-fixes-and-v126-delay/)

---

## 🟢 **Direct answer: Your crash *is fixed* in 1.24.11911.0**

The NT Compatible release notes explicitly state:

- **“Key fixes include resolving a tab‑dragging crash.”**  
- This fix is included in **Windows Terminal 1.24.11911.0** (stable) and **1.25.1912.0** (preview).   [NT Compatible](https://www.ntcompatible.com/story/windows-terminal-124-and-125-update-released-bug-fixes-and-v126-delay/)

This matches your crash signature exactly:

- Faulting module: **Microsoft.Terminal.Control.dll**  
- Exception: **0xc0000005**  
- Offset: **0x2C924**  
- Version: **1.24.2605.12001**  
- Trigger: **drag‑merging tabs**  
  (Confirmed in GitHub issue #20406)   [Github](https://github.com/microsoft/terminal/issues/20406)

The fix is described as correcting an **EnablePainting viewport desync** that caused crashes during tab dragging between windows of different sizes.   [NT Compatible](https://www.ntcompatible.com/story/windows-terminal-124-and-125-update-released-bug-fixes-and-v126-delay/)

---

## 🧩 **Important nuance: Some *other* tab‑drag crashes still exist**

While your specific crash (faulting in *Microsoft.Terminal.Control.dll*) is fixed, **newer related crashes** were later discovered:

- Crashes when dragging a tab **over terminal content** (not merging)  
  → Faulting in **Windows.UI.Xaml.dll**, exception **0xc000027b**  
  → Still present in 1.24.11911.0 and 1.24.2607.10001  
    [Github](https://github.com/microsoft/terminal/issues/20512)

- Crashes during pointer‑move events due to a race condition  
  → Null dereference in `TermControl::_PointerMovedHandler`  
  → Present in 1.24.11911.0  
    [Github](https://github.com/microsoft/terminal/issues/20477)

These are **different bugs** from yours, with different faulting modules and exception codes.

**Your crash is fixed.**  
**Other drag‑related crashes still exist.**

---

## 🛠 **What you should do now**

### 1. Update Windows Terminal  
Install **1.24.11911.0** or newer:

- Microsoft Store  
- `winget upgrade --id Microsoft.WindowsTerminal`  
- GitHub releases

This update contains the fix for your exact crash.

### 2. If you still see crashes  
They may be one of the newer XAML drag‑boundary bugs.  
Those are still under active investigation.

---

## 🔍 Want me to check your exact version and confirm?  
You can ask:  
- **Check my Windows Terminal version**  
- **Explain how to update Windows Terminal**
"

At least Microsoft fixes bugs, this was a really bad one, going to update my Windows Terminal, or at least try !

Amazing how the AI was able to figure this out and yes indeed it surprisingly took down all cmd/consoles...

This could be nasty for blockchains or lengthy setup of software.

So definetly a must fix.

Bye for now,
  Skybuck.

Re: AI Textconv filter misconfiguration on Windows leads to silent corruption of diff output (ongoing investigation)

[Theodore Tso]

On Tue, Aug 11, 2026 at 02:13:25AM -0500, Skybuck Flying wrote:
> 
> So sed removes literal 'r' instead of carriage returns. It appears that on
> Windows, the backslash in `\r` is not preserved through MSYS argument parsing,
> effectively turning the expression into `s/r//`.

The reason for this confusion is historical in nature and has to do
with a fundamental difference between Windows and Unix.  First,
understand that Unix predates Windows, with Unix being first developed
by AT&T Bell Labs in 1969, where as Windows dates from 1985, with DOS
dating from 1981.  Unix uses the forward slash ('/') as a path
separator.  However Windows and DOS uses the backwards slash ('\') as
a path separator, since DOS 1.0 used forward slashes for command-line
switches --- e.g., DIR/W.

Since Windows and DOS uses backwards slash as a path separator, it
can't be used as a quoting character, which is how Unix and Linux
interprets the backlash character.  Since MSYS (which is not developed
by the Windows Git team; they just use it), attempts to be compatible
with Unix / Linux, it uses backslash as quoting character.  CMD.EXE
and Powershell are Windows programs, which doesn't attempt to be Unix
compatible.

This is the nature of your confusion.  It's unfortunate that you find
this to be so irritating, but it's fundamentally because DOS/Windows
chose, back in the early 1980's, to be incompatible with Unix.  I
personally find Windows conventions to be irritating, and my way of
dealing with the problem is to avoid using Windows whenever possible.
Instead, I use MacOS and Linux, which doesn't have these Windows
compatibility problems.  Feel free to not use git, and to avoid
anything else which attempts to be compatible with Unix or Linux if
that brings you peace.  I certainly was much happier once I no longer
had to deal with Windows as part of my day job.  :-)

Cheers,

						- Ted

Re: AI Textconv filter misconfiguration on Windows leads to silent corruption of diff output (ongoing investigation)

[Jeff King]

On Tue, Aug 11, 2026 at 12:44:42AM +0000, Skybuck Flying wrote:

> - compareCache appeared as compaeCache
> - return appeared as eturn
> - from appeared as fom
> - var appeared as va
> - for appeared as fo
> - cacheReader appeared as cacheReade
> - CompareAndSwap appeared as CompaeAndSwap

So all of your r's are gone...

> Global .gitconfig:
> diff.lfclean.textconv=sed -e s/\r//

...and here you don't quote against the shell. So the shell is probably
converting "\r" into just "r", and thus sed is removing them.

The same thing would be a problem on Linux as well as Windows.

I felt clever at spotting this immediately, but then this is already in
your text later:

> So the command does strip the literal character 'r' instead of
> carriage returns. The likely reason is that the backslash before r is
> not preserved through the shell argument parsing on Windows;
> effectively, the expression becomes s/r//, which deletes all 'r'
> characters.

So...what's the question? This is a misconfiguration on your part.
Perhaps Git's documentation could be more clear that there will be a
shell involved, but using a shell is normal for (almost) all
user-specified commands run by Git.

-Peff