Re: [PATCH v3] apply.c: fix -p argument parsing

From: Jeff King <peff@peff.net>
Date: Mar 13, 2026, 01:29 UTC
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:

Show 13 quoted lines

> 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