On Thu, Aug 29, 2024 at 04:13:14PM -0700, Junio C Hamano wrote:
> Rubén Justo <rjusto@xxxxxxxxx> 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:
