Inconsistent handling of corrupt patches based on line endings

[Peregi Tamás <petamas@xxxxxxxxx>]

Hi all,

I might've found an inconsistency in how git-apply treats corrupt patches (representing empty context lines with completely empty lines instead of lines containing a single space - usually a result of a "trim trailing whitespace" editor setting) based on whether the patch file uses Windows-style line endings (CRLF) or Unix-style line endings (LF only). 

Regardless of whether I use LF or CRLF in original.txt, "git apply --check --ignore-whitespace" will happily apply intact-win.patch (uncorrupted patch file with CRLF), intact-unix.patch (uncorrupted patch file with LF) and corrupt-unix.patch (corrupted patch file with LF), but reports "error: corrupt patch at line 6" for corrupt-win.patch (corrupted patch file with CRLF).

My intuition tells me git-apply should either fail for all corrupt patch files (regardless of EOL) or it should apply the corrupt patch to work around the issue caused by misconfigured text editors (regardless of EOL).

Am I missing something, or is this a bug/inconsistency in git-apply's behaviour?

Thanks in advance: Tamás Peregi

**What did you do before the bug happened? (Steps to reproduce your issue)**

1. Rename either original-win.txt or original-unix.txt to original.txt
2. Run the following commands:
2.1. git apply --check --ignore-whitespace intact-unix.patch
2.2. git apply --check --ignore-whitespace intact-win.patch
2.3. git apply --check --ignore-whitespace corrupt-unix.patch
2.4. git apply --check --ignore-whitespace corrupt-win.patch

**What did you expect to happen? (Expected behavior)**

I'd expect one of the following:
- All 4 commands succeed.
- 2.1 and 2.2 succeeds, 2.3 and 2.4 both fail with "error: corrupt patch at line 6"

In other words: corrupted patches should either be accepted or not, regardless of what EOL markers are used in the patch file.

**What happened instead? (Actual behavior)**

Only 2.4, i.e. applying corrupt-win.patch has failed.

**What's different between what you expected and what actually happened?**

2.3 and 2.4 should have the same result.

**Anything else you want to add:**

While the example seems contrived, it has been encountered in the wild when I was copying a port from https://github.com/microsoft/vcpkg (set up with autocrlf=false and all files treated as binaries in .gitattributes) to my company's repository (set up with autocrlf=true and patch files treated as text). The patches and application worked in Microsoft's repo, then worked on my machine (Windows) in our repor, but failed in CI on Windows, and started failing on my machine after switching to a different branch and switching back due to "git checkout" converting the newline characters.

I think these kind of corrupt patch files should fail to apply consistently, but being able to apply them is also acceptable. However, the current inconsistent behaviour (apply if patch is LF, but fail if patch is CRLF) is confusing, and causes "works on my machine" issues.

[System Info]
git version:
git version 2.46.0.windows.1
cpu: x86_64
built from commit: 2e6a859ffc0471f60f79c1256f766042b0d5d17d
sizeof-long: 4
sizeof-size_t: 8
shell-path: D:/git-sdk-64-build-installers/usr/bin/sh
feature: fsmonitor--daemon
libcurl: 8.9.0
OpenSSL: OpenSSL 3.2.2 4 Jun 2024
zlib: 1.3.1
uname: Windows 10.0 19045
compiler info: gnuc: 14.1
libc info: no libc information available
$SHELL (typically, interactive shell): C:\Program Files\Git\usr\bin\bash.exe

a

b
c
d
e

f

Attachment: intact-win.patch
Description: Binary data

Attachment: intact-unix.patch
Description: Binary data

Attachment: corrupt-unix.patch
Description: Binary data

Attachment: corrupt-win.patch
Description: Binary data

a

b
c
d
e

f