From: Patrick Steinhardt <ps@pks.im>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 3/5] patch-id: make get_one_patchid() more extensible
Date: Mon, 29 Jul 2024 14:02:32 +0200 [thread overview]
Message-ID: <ZqeE2IaIhiWmpVM4@tanuki> (raw)
In-Reply-To: <20240621231826.3280338-4-gitster@pobox.com>
[-- Attachment #1: Type: text/plain, Size: 2351 bytes --]
On Fri, Jun 21, 2024 at 04:18:24PM -0700, Junio C Hamano wrote:
> We pass two independent Boolean flags (i.e. do we want the stable
> variant of patch-id? do we want to hash the stuff verbatim?) into
> the function as two separate parameters. Before adding the third
> one and make the interface even wider, let's consolidate them into
> a single flag word.
>
> No changes in behaviour. Just a trivial interface change.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> builtin/patch-id.c | 20 +++++++++++++++-----
> 1 file changed, 15 insertions(+), 5 deletions(-)
>
> diff --git a/builtin/patch-id.c b/builtin/patch-id.c
> index 0f262e7a03..128e0997d8 100644
> --- a/builtin/patch-id.c
> +++ b/builtin/patch-id.c
> @@ -58,9 +58,14 @@ static int scan_hunk_header(const char *p, int *p_before, int *p_after)
> return 1;
> }
>
> +#define GOPID_STABLE 01
> +#define GOPID_VERBATIM 02
> +
This certainly is a worthwhile change. I have to wonder about code style
though:
- Using 01 and 02 as constants feels somewhat weird to me. Don't we
typically use `(1 << 0)` and `(1 << 1)` for such binary flags?
- What is our preferred style nowadays? Do we prefer defines over
enums? I rather had the feeling that enums are the go-to style for
things like this nowadays.
It would also be nice to have documentation for the flags.
In any case, all of these are really just smallish nits and I think that
this is a strict improvement regardless of whether we massage the style
or not.
> @@ -237,7 +243,11 @@ int cmd_patch_id(int argc, const char **argv, const char *prefix)
> argc = parse_options(argc, argv, prefix, builtin_patch_id_options,
> patch_id_usage, 0);
>
> - generate_id_list(opts ? opts > 1 : config.stable,
> - opts ? opts == 3 : config.verbatim);
> + if (opts ? opts > 1 : config.stable)
> + flags |= GOPID_STABLE;
> + if (opts ? opts == 3 : config.verbatim)
> + flags |= GOPID_VERBATIM;
I was wondering whether we could use `OPT_BIT()` here to set those as
flags directly. I guess that would require a bit more refactoring, but
if we also converted `struct patch_id_opts` to have a `flags` field then
this might overall be easier to read than the weird massaging of opts
that we did before and after your change.
Patrick
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2024-07-29 12:02 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-21 23:18 [PATCH 0/5] Tighten patch header parsing in patch-id Junio C Hamano
2024-06-21 23:18 ` [PATCH 1/5] t4204: patch-id supports various input format Junio C Hamano
2024-06-21 23:18 ` [PATCH 2/5] patch-id: call flush_current_id() only when needed Junio C Hamano
2024-06-21 23:18 ` [PATCH 3/5] patch-id: make get_one_patchid() more extensible Junio C Hamano
2024-07-29 12:02 ` Patrick Steinhardt [this message]
2024-07-29 20:03 ` Junio C Hamano
2024-06-21 23:18 ` [PATCH 4/5] patch-id: rewrite code that detects the beginning of a patch Junio C Hamano
2024-07-29 12:03 ` Patrick Steinhardt
2024-06-21 23:18 ` [PATCH 5/5] patch-id: tighten code to detect the patch header Junio C Hamano
2024-07-29 12:07 ` Patrick Steinhardt
2024-07-29 20:12 ` Junio C Hamano
2024-07-30 4:55 ` Patrick Steinhardt
2024-07-30 5:12 ` Patrick Steinhardt
2024-07-30 1:17 ` [PATCH v2 0/5] Tighten patch header parsing in patch-id Junio C Hamano
2024-07-30 1:17 ` [PATCH v2 1/5] t4204: patch-id supports various input format Junio C Hamano
2024-07-30 1:17 ` [PATCH v2 2/5] patch-id: call flush_current_id() only when needed Junio C Hamano
2024-07-30 1:17 ` [PATCH v2 3/5] patch-id: make get_one_patchid() more extensible Junio C Hamano
2024-07-30 1:17 ` [PATCH v2 4/5] patch-id: rewrite code that detects the beginning of a patch Junio C Hamano
2024-07-30 1:17 ` [PATCH v2 5/5] patch-id: tighten code to detect the patch header Junio C Hamano
2024-07-30 5:12 ` [PATCH v2 0/5] Tighten patch header parsing in patch-id Patrick Steinhardt
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=ZqeE2IaIhiWmpVM4@tanuki \
--to=ps@pks.im \
--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 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.