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

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: [email protected]
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.