From: Rubén Justo <rjusto@gmail.com>
Date: Tue, 03 Sep 2024 22:06:10 GMT
Subject: Re: [PATCH 2/5] apply: honor `ignore_ws_none` with `correct_ws_error`
Message-ID: <50d85a93-6711-4b42-87a5-f26b58b8c5c7@gmail.com>
In-Reply-To: <xmqqed66udmd.fsf@gitster.g>

On Thu, Aug 29, 2024 at 04:13:14PM -0700, Junio C Hamano wrote:
> Rubén Justo <rjusto@gmail.com> writes:
> 
> > I'm not very happy with the new enum, but I haven't come up with a
> > better idea.
> > ...
> > None of them are better, I think.
> 
> Not adding a new enum is probably much better.  See the "additional
> thought" in my review on [3/5], for example.

If I understand correctly the example you mentioned, using
`in_fn_table()` cannot help us in `parse_fragment()`.  But I could be
completely wrong and misunderstanding your intention.

I still don't see a better option than introducing a new value
`default`.  Perhaps described like this:

diff --git a/Documentation/config/apply.txt b/Documentation/config/apply.txt
index f9908e210a..7b642d2f3a 100644
--- a/Documentation/config/apply.txt
+++ b/Documentation/config/apply.txt
@@ -4,6 +4,10 @@ apply.ignoreWhitespace::
        option.
        When set to one of: no, none, never, false, it tells 'git apply' to
        respect all whitespace differences.
+       When not set or set to `default`, it tells `git apply` to
+       behave like the previous setting: `no`.  However, when
+       combined with 'whitespace=fix', some whitespace errors
+       will still be ignored because they are being fixed.
        See linkgit:git-apply[1].

 apply.whitespace: