From: Junio C Hamano <gitster@pobox.com>
To: "Philippe Blain via GitGitGadget" <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, Emily Shaffer <emilyshaffer@google.com>,
Glen Choo <chooglen@google.com>,
Philippe Blain <levraiphilippeblain@gmail.com>
Subject: Re: [PATCH] submodule.h: use a named enum for RECURSE_SUBMODULES_*
Date: Wed, 05 Jan 2022 13:20:36 -0800 [thread overview]
Message-ID: <xmqq1r1lhobf.fsf@gitster.g> (raw)
In-Reply-To: <pull.1111.git.1641410782015.gitgitgadget@gmail.com> (Philippe Blain via GitGitGadget's message of "Wed, 05 Jan 2022 19:26:21 +0000")
"Philippe Blain via GitGitGadget" <gitgitgadget@gmail.com> writes:
> From: Philippe Blain <levraiphilippeblain@gmail.com>
>
> Using a named enum allows casting an integer to the enum type in both
> GDB and LLDB:
>
> (gdb) p (enum diff_submodule_format) options->submodule_format
> $1 = DIFF_SUBMODULE_LOG
Hmph, this was somewhat unexpected and quite disappointing.
Because that's not what those "Let's move away from #define'd
constants and use more enums" said when they sold their "enum" to
us. In the diff_options struct, the .submodule_format member is of
type enum already, so, if we trust what they told us when they sold
their enums, "p options->submodule_format" should be enough to give
us "DIFF_SUBMODULE_LOG", not "1", as its output. Do you really need
the cast in the above example?
> Name the enum listing the different RECURSE_SUBMODULES_* modes, to make
> debugging easier.
Even though this patch may be a good single step in the right
direction, until it is _used_ to declare a variable or a member of a
struct of that enum type, it probably is not useful as much as it
could be. The user needs to know which enum is stored in that "int"
variable or member the user is interested in to cast it to.
That is, many changes like this one.
diff --git i/builtin/pull.c w/builtin/pull.c
index c8457619d8..f2fd4784df 100644
--- i/builtin/pull.c
+++ w/builtin/pull.c
@@ -71,7 +71,7 @@ static const char * const pull_usage[] = {
/* Shared options */
static int opt_verbosity;
static char *opt_progress;
-static int recurse_submodules = RECURSE_SUBMODULES_DEFAULT;
+static enum submodule_recurse_mode recurse_submodules = RECURSE_SUBMODULES_DEFAULT;
/* Options passed to git-merge or git-rebase */
static enum rebase_type opt_rebase = -1;
next prev parent reply other threads:[~2022-01-05 21:20 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-05 19:26 [PATCH] submodule.h: use a named enum for RECURSE_SUBMODULES_* Philippe Blain via GitGitGadget
2022-01-05 21:20 ` Junio C Hamano [this message]
2022-01-07 13:27 ` Philippe Blain
2022-01-07 17:43 ` Glen Choo
2022-01-18 18:20 ` Glen Choo
2022-04-04 17:10 ` [PATCH v2] " Philippe Blain via GitGitGadget
2022-04-04 17:52 ` Glen Choo
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=xmqq1r1lhobf.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=chooglen@google.com \
--cc=emilyshaffer@google.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=levraiphilippeblain@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.
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).