git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Inconsistent handling of corrupt patches based on line endings
@ 2024-10-28 16:57 Peregi Tamás
  2024-10-28 18:11 ` Taylor Blau
  2024-10-29 16:32 ` Torsten Bögershausen
  0 siblings, 2 replies; 6+ messages in thread
From: Peregi Tamás @ 2024-10-28 16:57 UTC (permalink / raw)
  To: git


[-- Attachment #1.1: Type: text/plain, Size: 3508 bytes --]

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

[-- Attachment #1.2: Type: text/html, Size: 3821 bytes --]

[-- Attachment #2: original-unix.txt --]
[-- Type: text/plain, Size: 14 bytes --]

a

b
c
d
e

f

[-- Attachment #3: intact-win.patch --]
[-- Type: application/octet-stream, Size: 165 bytes --]

diff --git a/original.txt b/original.txt
index e7582b7..940b5a6 100644
--- a/original.txt
+++ b/original.txt
@@ -2,6 +2,7 @@ a
 
 b
 c
+NEW LINE
 d
 e
 

[-- Attachment #4: intact-unix.patch --]
[-- Type: application/octet-stream, Size: 153 bytes --]

diff --git a/original.txt b/original.txt
index e7582b7..940b5a6 100644
--- a/original.txt
+++ b/original.txt
@@ -2,6 +2,7 @@ a
 
 b
 c
+NEW LINE
 d
 e
 

[-- Attachment #5: corrupt-unix.patch --]
[-- Type: application/octet-stream, Size: 151 bytes --]

diff --git a/original.txt b/original.txt
index e7582b7..940b5a6 100644
--- a/original.txt
+++ b/original.txt
@@ -2,6 +2,7 @@ a

 b
 c
+NEW LINE
 d
 e


[-- Attachment #6: corrupt-win.patch --]
[-- Type: application/octet-stream, Size: 163 bytes --]

diff --git a/original.txt b/original.txt
index e7582b7..940b5a6 100644
--- a/original.txt
+++ b/original.txt
@@ -2,6 +2,7 @@ a

 b
 c
+NEW LINE
 d
 e


[-- Attachment #7: original-win.txt --]
[-- Type: text/plain, Size: 22 bytes --]

a

b
c
d
e

f

^ permalink raw reply related	[flat|nested] 6+ messages in thread
end of thread, other threads:[~2024-10-29 16:32 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-10-28 16:57 Inconsistent handling of corrupt patches based on line endings Peregi Tamás
2024-10-28 18:11 ` Taylor Blau
2024-10-28 18:39   ` Elijah Newren
2024-10-28 22:07     ` René Scharfe
2024-10-28 22:59       ` Junio C Hamano
2024-10-29 16:32 ` Torsten Bögershausen

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).