From: Jeff King <peff@peff.net>
Date: Fri, 13 Mar 2026 01:29:05 GMT
Subject: Re: [PATCH v3] apply.c: fix -p argument parsing
Message-ID: <20260313012905.GA3749719@coredump.intra.peff.net>
In-Reply-To: <20260313011259.GA3204960@coredump.intra.peff.net>

On Thu, Mar 12, 2026 at 09:12:59PM -0400, Jeff King wrote:

> Getting back to your patch: why is there a CRLF here in the first place?
> Because on Windows, we check out the whole repo with CRLF conversion,
> except for a few known file types listed in .gitattributes. And that
> includes your t/t4120/patch file.
> 
> Coincidentally the style suggestion I made earlier, to just inline it in
> the t4120 script itself, makes the problem go away. Because we check out
> those scripts with bare line feeds, per .gitattributes, the file we
> create will also have regular line feeds.
> 
> So I would suggest doing that as a workaround. It might be worth
> addressing the CRLF header parsing problem above, too, but I think that
> should be a separate topic.

In case we want to pursue the CRLF thing further, you can demonstrate it
on Linux easily with:

  {
    printf 'diff --git a/file b/file\r\n'
    printf 'old mode 100644'
    printf 'new mode 100755'
  } >patch
  git apply patch

I was surprised that we wouldn't hit this case _somewhere_ in the test
suite already, and indeed we do. Even with a separate patch file, like
you have! But the tests pass due to 614f4f0f35 (Fix the remaining tests
that failed with core.autocrlf=true, 2017-05-09), which explicitly adds
.gitattributes for "t/t4101/*", etc.

So that's another workaround for your patch: we could mark the directory
with .gitattributes in the same way. I still prefer inlining the patch
in the script for style reasons, though.

-Peff