From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Phillip Wood <phillip.wood@dunelm.org.uk>
Cc: "Junio C Hamano" <gitster@pobox.com>,
"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
"Phillip Wood via GitGitGadget" <gitgitgadget@gmail.com>,
git@vger.kernel.org, "SZEDER Gábor" <szeder.dev@gmail.com>
Subject: Re: [PATCH v2 0/2] builtin add -p: fix hunk splitting
Date: Sat, 22 Jan 2022 10:05:14 +0100 (CET) [thread overview]
Message-ID: <nycvar.QRO.7.76.6.2201220938360.2121@tvgsbejvaqbjf.bet> (raw)
In-Reply-To: <47e7b23a-56a3-b533-63ed-a854503b59ed@gmail.com>
Hi Phillip,
first of all: thank you for these patches. I read over them and they have
my ACK.
On Wed, 19 Jan 2022, Phillip Wood wrote:
> On 12/01/2022 18:51, Junio C Hamano wrote:
> > Phillip Wood <phillip.wood123@gmail.com> writes:
> >
> > > I'm not sure I want to go with your extra changes. I've left some
> > > comments on them below
> > >
> > > > @@ -488,12 +499,12 @@ static int parse_diff(struct add_p_state *s, const
> > > > struct pathspec *ps)
> > > > else if (starts_with(p, "@@ ") ||
> > > > (hunk == &file_diff->head &&
> > > > (skip_prefix(p, "deleted file", &deleted)))) {
> > > > - if (marker == '-' || marker == '+')
> > > > - /*
> > > > - * Should not happen; previous hunk did not end
> > > > - * in a context line? Handle it anyway.
> > > > - */
> > > > + hunk->splittable_into++;
> > > > + /*
> > > > + * Should not increment "splittable_into";
> > > > + * previous hunk did not end in a context
> > > > + * line? Handle it anyway.
> > > > + */
> > > > + complete_file(marker, &hunk->splittable_into);
> > > > ALLOC_GROW_BY(file_diff->hunk, file_diff->hunk_nr, 1,
> > > > file_diff->hunk_alloc);
> > >
> > > I deliberately left this alone as I think we should probably make
> > > this BUG() out instead of silently accepting an invalid diff.
FWIW this was overzealous defensive programming on my part. More on that
below.
> > As we are reading our own output, I agree that such a data error is
> > a BUG().
Indeed. I was less worried about the output format changing, and more
concerned with bugs in my parser ;-)
Although, having said that, I had meant to verify that `git add -p` cannot
be asked to produce and consume diffs with `-U0` when I wrote that
comment. Now I did that, and I am now confident that there is no way to ask
`git add -p` to generate and use context line-free diffs: we neither add
`-U<n>` in https://github.com/git/git/blob/v2.34.1/add-patch.c#L398-L417
nor do we call the user-facing `git diff` command that would interpret
`diff.context`, but instead we use `git diff-index` and `git diff-files`
(which ignore that config setting).
> > In any case, a helper to see if the file ended without post-context
> > is one thing, and a helper that specify what happens after we are
> > done with a single file, before we move on top the next file or
> > after processing the last file, is another thing. The latter may be
> > able to make use of the former, but the latter may want to do more
> > than that in the future.
If you are concerned about the name of the function: maybe a better name
would be `maybe_increment_splittable_hunk_count(marker)`.
> >
> > As complete_file() is about finalizing the processing we have done
> > to the current file, it should be used for that purpose, and nothing
> > else, I think the hunk I see at
> > https://github.com/git/git/commit/c082176f8c5a1fc1c8b2a93991ca28fd63aae73a
> > (reproduced below) is simply a nonsense.
> >
> > Stepping back a bit, though, is this helper really finalizing the
> > current file, or is it finalizing the current hunk? If it were the
> > latter, then its use in the hunk I called "nonsense" above actually
> > makes perfect sense.
>
> Even if the helper is finalizing the current hunk then I think that "nonsense"
> hunk would still wrong as it would be calling finalize_hunk() on _every_
> context line in the hunk rather than just being called once to finalize the
> hunk. We could call the function something like update_splittable() but then
> we'd need to explain why we were calling that function at the start of a diff
> and at the end of the loop.
Right. The point of this check is to see whether we missed counting a
splittable hunk. Then it makes more sense to call it at the beginning of a
file, at the end of a file _and_ at a context line.
Having said all that, I am really fine with what landed in `next`.
Thank you,
Dscho
next prev parent reply other threads:[~2022-01-22 9:05 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-20 14:32 [PATCH 0/2] builtin add -p: fix hunk splitting Phillip Wood via GitGitGadget
2021-12-20 14:32 ` [PATCH 1/2] t3701: clean up hunk splitting tests Phillip Wood via GitGitGadget
2021-12-20 21:09 ` Junio C Hamano
2021-12-20 14:32 ` [PATCH 2/2] builtin add -p: fix hunk splitting Phillip Wood via GitGitGadget
2021-12-20 19:06 ` Ævar Arnfjörð Bjarmason
2022-01-11 11:13 ` Phillip Wood
2022-01-11 11:44 ` Ævar Arnfjörð Bjarmason
2021-12-20 21:30 ` Junio C Hamano
2022-01-11 11:12 ` [PATCH v2 0/2] " Phillip Wood via GitGitGadget
2022-01-11 11:12 ` [PATCH v2 1/2] t3701: clean up hunk splitting tests Phillip Wood via GitGitGadget
2022-01-11 11:12 ` [PATCH v2 2/2] builtin add -p: fix hunk splitting Phillip Wood via GitGitGadget
2022-01-11 12:07 ` [PATCH v2 0/2] " Ævar Arnfjörð Bjarmason
2022-01-11 18:57 ` Phillip Wood
2022-01-12 18:51 ` Junio C Hamano
2022-01-19 20:01 ` Phillip Wood
2022-01-20 5:02 ` Junio C Hamano
2022-01-20 8:42 ` Ævar Arnfjörð Bjarmason
2022-01-20 19:13 ` Junio C Hamano
2022-01-22 9:05 ` Johannes Schindelin [this message]
2022-01-24 11:10 ` Phillip Wood
2022-01-12 18:34 ` Junio C Hamano
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=nycvar.QRO.7.76.6.2201220938360.2121@tvgsbejvaqbjf.bet \
--to=johannes.schindelin@gmx.de \
--cc=avarab@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=gitster@pobox.com \
--cc=phillip.wood@dunelm.org.uk \
--cc=szeder.dev@gmail.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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).