From: Junio C Hamano <gitster@pobox.com>
To: "Phillip Wood via GitGitGadget" <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org,
Johannes Schindelin <Johannes.Schindelin@gmx.de>,
Phillip Wood <phillip.wood@dunelm.org.uk>
Subject: Re: [PATCH 0/2] add p in C tweaks
Date: Tue, 18 Aug 2020 12:44:42 -0700 [thread overview]
Message-ID: <xmqqmu2ryc0l.fsf@gitster.c.googlers.com> (raw)
In-Reply-To: <pull.702.git.1597670589.gitgitgadget@gmail.com> (Phillip Wood via GitGitGadget's message of "Mon, 17 Aug 2020 13:23:06 +0000")
"Phillip Wood via GitGitGadget" <gitgitgadget@gmail.com> writes:
> A code cleanup and small bug fix for the C version of add -p
>
> dscho has pointed out that the bug fix in the second patch gets lost in the
> other changes and suggested adding the last member of the enum (which fixes
> the bug with handling 'e') as a separate patch. I'm unsure as it feels odd
> to split up the introduction of the flags - I'd be interested to hear what
> others think.
Essentially, the original was doing:
- In early part of patch_update_file(), decide what option to show
in s->buf using "if (undecided_previous >= 0)" etc. boolean
expression that is tailored for each command;
- In later part of patch_update_file(), after getting an answer
to the end user, try to use the same boolean expression that
is tailored for each command to see if the given command is
acceptable.
and the bug was that each pair of boolean expressions that are
supposed to be identical were duplicated in two places, and one pair
was not identical by mistake.
Your [2/2] fixes it by turning the above to
- In early part of patch_update_file(), decide what option to show
in s->buf using "if (undecided_previous >= 0)" etc. boolean
expression that is tailored for each command, *AND* record the
fact that the command is allowed in the permitted bitmask.
- In later part of patch_update_file(), after getting an answer
to the end user, consult the permitted bitmask computed
earlier to see if the given command is acceptable.
Since there no longer is duplicated boolean expressions that are
supposed to be the same but different by a bug, once this conversion
is made, it is impossible to have the bug. For that reason, I do
not think the suggested split makes much sense.
A much saner split, if we have to split this step into two, would be
to first fix the bug keeping the code structure of the original,
i.e. the later part guards the 'e' command with
if (hunk_index + 1 == file_diff->mode_change)
but the earlier part also required !file_diff->deleted, i.e. the
condition should have been
if (hunk_index + 1 > file_diff->mode_change && !file_diff->deleted)
So without introducing enum and permitted bitmask, you can fix the
bug in place, replacing the incorrect boolean condition in the later
part that guards the 'e' command with a corrected one. That would
be a minimum fix that can become your new [2/2], whose theme is "to
fix the bug with minumum change".
On top of that, you can convert the function again to reach the
final shape that writes each boolean condition only once and records
the permitted commands in the bitmask. That can be your new [3/2],
whose these is "to make it impossible to introduce the bug previous
step fixed".
> Phillip Wood (2):
> add -p: use ALLOC_GROW_BY instead of ALLOW_GROW
> add -p: fix checking of user input
>
> add-patch.c | 67 +++++++++++++++++++++++++++++++++--------------------
> 1 file changed, 42 insertions(+), 25 deletions(-)
>
>
> base-commit: 47ae905ffb98cc4d4fd90083da6bc8dab55d9ecc
> Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-702%2Fphillipwood%2Fwip%2Fadd-p-fixes-v1
> Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-702/phillipwood/wip/add-p-fixes-v1
> Pull-Request: https://github.com/gitgitgadget/git/pull/702
next prev parent reply other threads:[~2020-08-18 19:45 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-17 13:23 [PATCH 0/2] add p in C tweaks Phillip Wood via GitGitGadget
2020-08-17 13:23 ` [PATCH 1/2] add -p: use ALLOC_GROW_BY instead of ALLOW_GROW Phillip Wood via GitGitGadget
2020-08-17 18:35 ` Junio C Hamano
2020-08-17 13:23 ` [PATCH 2/2] add -p: fix checking of user input Phillip Wood via GitGitGadget
2020-08-18 6:38 ` Johannes Schindelin
2020-08-18 6:39 ` [PATCH 0/2] add p in C tweaks Johannes Schindelin
2020-08-18 19:44 ` Junio C Hamano [this message]
2020-08-19 9:59 ` Phillip Wood
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=xmqqmu2ryc0l.fsf@gitster.c.googlers.com \
--to=gitster@pobox.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--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.
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).