git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Rubén Justo" <rjusto@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Git List <git@vger.kernel.org>
Subject: Re: [PATCH 2/5] apply: honor `ignore_ws_none` with `correct_ws_error`
Date: Wed, 4 Sep 2024 00:06:10 +0200	[thread overview]
Message-ID: <50d85a93-6711-4b42-87a5-f26b58b8c5c7@gmail.com> (raw)
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:

  reply	other threads:[~2024-09-03 22:06 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-25 10:09 [PATCH 0/5] `--whitespace=fix` with `--no-ignore-whitespace` Rubén Justo
2024-08-25 10:17 ` [PATCH 1/5] apply: introduce `ignore_ws_default` Rubén Justo
2024-08-27  1:11   ` Junio C Hamano
2024-08-25 10:18 ` [PATCH 2/5] apply: honor `ignore_ws_none` with `correct_ws_error` Rubén Justo
2024-08-27  0:35   ` Junio C Hamano
2024-08-29  5:07     ` Rubén Justo
2024-08-29 23:13       ` Junio C Hamano
2024-09-03 22:06         ` Rubén Justo [this message]
2024-09-04  4:41           ` Junio C Hamano
2024-09-04 18:20             ` Rubén Justo
2024-08-25 10:18 ` [PATCH 3/5] apply: whitespace errors in context lines if we have Rubén Justo
2024-08-27  0:43   ` Junio C Hamano
2024-08-27  1:49     ` Junio C Hamano
2024-08-27 16:12       ` Junio C Hamano
2024-08-27  0:51   ` Junio C Hamano
2024-08-25 10:19 ` [PATCH 4/5] apply: error message in `record_ws_error()` Rubén Justo
2024-08-27  0:44   ` Junio C Hamano
2024-08-25 10:19 ` [PATCH 5/5] t4124: move test preparation into the test context Rubén Justo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50d85a93-6711-4b42-87a5-f26b58b8c5c7@gmail.com \
    --to=rjusto@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).