From: Phillip Wood <phillip.wood123@gmail.com>
To: Michael Lohmann <mi.al.lohmann@gmail.com>, git@vger.kernel.org
Cc: Wanja Henze <wanja.hentze@bevuta.com>
Subject: Re: [PATCH] builtin/revert.c: refactor using an enum for cmd-action
Date: Thu, 11 Jan 2024 16:57:26 +0000 [thread overview]
Message-ID: <1ed0e249-dab9-4cf3-9b76-c8797b97c9c5@gmail.com> (raw)
In-Reply-To: <20240111080417.59346-1-mi.al.lohmann@gmail.com>
Hi Michael
On 11/01/2024 08:04, Michael Lohmann wrote:
> This is done to avoid having to keep the char values in sync in
> different places and also to get compiler warnings on non-exhaustive
> switches.
I think this is a reasonable change, thanks for working on it.
> The newly introduced `revert_action`-enum aligns with the
> builtin/rebase.c `action`-enum though the name `revert_action` is chosen
> to better differentiate it from `replay_opts->action` with a different
> function. For rebase the equivalent of the latter is
> `rebase_options->type` and `rebase_options->action` corresponds to the
> `cmd` variable in revert.c.
>
> In the rebase `action` enum there is the enumeration constant
> `ACTION_NONE` which is not particularly descriptive, since it seems to
> imply that no action should be taken. Instead it signals a start of a
> revert/cherry-pick process, so here `REVERT_ACTION_START` was chosen.
I think ACTION_NONE was intended to covey that the user did not pass one
of the OPT_CMDMODE() options like "--continue" as there isn't a
"--start" option. I don't have a strong opinion between "_NONE" and
"_START".
> +enum revert_action {
> + REVERT_ACTION_START = 0,
> + REVERT_ACTION_CONTINUE,
> + REVERT_ACTION_SKIP,
> + REVERT_ACTION_ABORT,
> + REVERT_ACTION_QUIT,
> +};
The "REVERT_" prefix is a bit unfortunate as this is used by cherry-pick
as well but it does match the filename. As this enum is only used in
this file I'd be quite happy to drop the "REVERT_" prefix. (I don't
think we need to go messing with the "action" member of struct
replay_opts to do that)
> /* Check for incompatible command line arguments */
> - if (cmd) {
> - char *this_operation;
> - if (cmd == 'q')
> + {
> + char *this_operation = 0;
style note: we use "NULL" rather than "0" when initializing pointers.
Ideally this would be a "const char *" as we assign string literals but
that is not a new problem with this patch.
> + switch (cmd) {
> + case REVERT_ACTION_START:
> + break;
I can see the attraction of using an exhaustive switch() here but as we
don't want to do anything in the _START case it gets a bit messy with
the extra conditional below. I wonder if we'd be better to replace "if
(cmd) {" with "if (cmd != REVERT_ACTION_START) {". Alternatively if you
want to stick with the switch then declaring "this_operation" at the
beginning of the function would mean you can get rid of the new "{}" block.
> + case REVERT_ACTION_QUIT:
> this_operation = "--quit";
> - else if (cmd == 'c')
> + break;
> + case REVERT_ACTION_CONTINUE:
> this_operation = "--continue";
> - else if (cmd == 's')
> + break;
> + case REVERT_ACTION_SKIP:
> this_operation = "--skip";
> - else {
> - assert(cmd == 'a'); > + break;
> + case REVERT_ACTION_ABORT:
> this_operation = "--abort";
> + break;
> }
>
> - verify_opt_compatible(me, this_operation,
> - "--no-commit", opts->no_commit,
> - "--signoff", opts->signoff,
> - "--mainline", opts->mainline,
> - "--strategy", opts->strategy ? 1 : 0,
> - "--strategy-option", opts->xopts.nr ? 1 : 0,
> - "-x", opts->record_origin,
> - "--ff", opts->allow_ff,
> - "--rerere-autoupdate", opts->allow_rerere_auto == RERERE_AUTOUPDATE,
> - "--no-rerere-autoupdate", opts->allow_rerere_auto == RERERE_NOAUTOUPDATE,
> - NULL);
> + if (this_operation)
The extra indentation here is unfortunate as some of the lines are
rather long already. In the current code it is clear that we only call
verify_opt_compatible() when cmd is non-nul, I think it would be clearer
to use "if (cmd != REVERT_ACTION_START)" here.
> + verify_opt_compatible(me, this_operation,
> + "--no-commit", opts->no_commit,
> + "--signoff", opts->signoff,
> + "--mainline", opts->mainline,
> + "--strategy", opts->strategy ? 1 : 0,
> + "--strategy-option", opts->xopts.nr ? 1 : 0,
> + "-x", opts->record_origin,
> + "--ff", opts->allow_ff,
> + "--rerere-autoupdate", opts->allow_rerere_auto == RERERE_AUTOUPDATE,
> + "--no-rerere-autoupdate", opts->allow_rerere_auto == RERERE_NOAUTOUPDATE,
> + NULL);
> }
> [...]
> - if (cmd) {
> - opts->revs = NULL;
> - } else {
> + if (cmd == REVERT_ACTION_START) {
I was momentarily confused by this change but you're reversing the
conditional. I agree that the result is an improvement.
Best Wishes
Phillip
next prev parent reply other threads:[~2024-01-11 16:57 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-11 8:04 [PATCH] builtin/revert.c: refactor using an enum for cmd-action Michael Lohmann
2024-01-11 16:57 ` Phillip Wood [this message]
2024-01-11 17:47 ` [PATCH v2] " Michael Lohmann
2024-01-11 19:50 ` Junio C Hamano
2024-01-11 20:06 ` [PATCH v3] " Michael Lohmann
2024-01-11 21:47 ` Junio C Hamano
2024-01-12 0:40 ` Junio C Hamano
2024-01-12 7:24 ` Jeff King
2024-01-12 18:13 ` Junio C Hamano
2024-01-12 19:33 ` Michael Lohmann
2024-01-11 19:37 ` [PATCH] " 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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1ed0e249-dab9-4cf3-9b76-c8797b97c9c5@gmail.com \
--to=phillip.wood123@gmail.com \
--cc=git@vger.kernel.org \
--cc=mi.al.lohmann@gmail.com \
--cc=phillip.wood@dunelm.org.uk \
--cc=wanja.hentze@bevuta.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).