From: Junio C Hamano <gitster@pobox.com>
To: "Phillip Wood via GitGitGadget" <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, Jeff King <peff@peff.net>,
Phillip Wood <phillip.wood@dunelm.org.uk>
Subject: Re: [PATCH] add-patch: handle splitting hunks with diff.suppressBlankEmpty
Date: Thu, 18 Jul 2024 09:29:35 -0700 [thread overview]
Message-ID: <xmqqikx2wtn4.fsf@gitster.g> (raw)
In-Reply-To: <pull.1763.git.1721312619822.gitgitgadget@gmail.com> (Phillip Wood via GitGitGadget's message of "Thu, 18 Jul 2024 14:23:39 +0000")
"Phillip Wood via GitGitGadget" <gitgitgadget@gmail.com> writes:
> From: Phillip Wood <phillip.wood@dunelm.org.uk>
>
> When "add -p" parses diffs, it looks for context lines starting with a
> single space. But when diff.suppressBlankEmpty is in effect, an empty
> context line will omit the space, giving us a true empty line. This
> confuses the parser, which is unable to split based on such a line.
>
> It's tempting to say that we should just make sure that we generate a
> diff without that option. However, although we do not parse hunks that
> the user has manually edited with parse_diff() we do allow the user
> to split such hunks. As POSIX calls the decision of whether to print the
> space here "implementation-defined" we need to handle edited hunks where
> empty context lines omit the space.
>
> So let's handle both cases: a context line either starts with a space or
> consists of a totally empty line by normalizing the first character to a
> space when we parse them. Normalizing the first character rather than
> changing the code to check for a space or newline will hopefully future
> proof against introducing similar bugs if the code is changed.
>
> Reported-by: Ilya Tumaykin <itumaykin@gmail.com>
> Helped-by: Jeff King <peff@peff.net>
> Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk>
> ---
Well written. Thanks for a pleasant read.
> @@ -953,7 +960,7 @@ static int split_hunk(struct add_p_state *s, struct file_diff *file_diff,
> context_line_count = 0;
>
> while (splittable_into > 1) {
> - ch = s->plain.buf[current];
> + ch = normalize_marker(s->plain.buf + current);
I wondered if &s->plain.buf[current] is easier to grok, but what's
written already is good enough ;-)
There is another explicit mention of ' ' in merge_hunks(). Unless
we are normalizing the buffer here (which I do not think we do),
wouldn't we have to make sure that the code over there also knows
that an empty line in a patch is an unmodified empty line?
if (plain[overlap_end] != ' ')
return error(_("expected context line "
"#%d in\n%.*s"),
next prev parent reply other threads:[~2024-07-18 16:29 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-18 14:23 [PATCH] add-patch: handle splitting hunks with diff.suppressBlankEmpty Phillip Wood via GitGitGadget
2024-07-18 16:29 ` Junio C Hamano [this message]
2024-07-19 15:17 ` Phillip Wood
2024-07-20 16:01 ` [PATCH v2 0/2] " Phillip Wood via GitGitGadget
2024-07-20 16:01 ` [PATCH v2 1/2] " Phillip Wood via GitGitGadget
2024-07-20 16:02 ` [PATCH v2 2/2] add-patch: use normalize_marker() when recounting edited hunk Phillip Wood via GitGitGadget
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=xmqqikx2wtn4.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=peff@peff.net \
--cc=phillip.wood@dunelm.org.uk \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.