From: Junio C Hamano <gitster@pobox.com>
To: K Jayatheerth <jayatheerthkulkarni2005@gmail.com>
Cc: nasamuffin@google.com, git@vger.kernel.org
Subject: Re: [PATCH v2 2/3] docs: clarify cmd_psuh signature and explain UNUSED macro
Date: Sat, 17 May 2025 06:39:38 -0700 [thread overview]
Message-ID: <xmqq34d3s6ed.fsf@gitster.g> (raw)
In-Reply-To: <20250516185516.52311-2-jayatheerthkulkarni2005@gmail.com> (K. Jayatheerth's message of "Sat, 17 May 2025 00:25:15 +0530")
K Jayatheerth <jayatheerthkulkarni2005@gmail.com> writes:
> The documentation previously omitted the UNUSED macro,
> which often led to confusion for new contributors
> when they encountered compiler warnings related to unused parameters.
The above is not quite easy to reason about. It is more like we
wrote this document, and then later tightened the default compiler
warnings for developer builds. So "omitted" may technically be
correct, but it was more like "did not use it, because there was no
need".
The sample program, as written, would not build for at least two
reasons:
- Since this document was first written, the calling convention
to subcommand implementation has changed, and now cmd_psuh()
needs to accept the third parameter, repository.
- These days, compiler warning options for developers include
one that detects and complains about unused parameters, so
ones that are deliberately unused have to be marked as such.
After such observation on the status quo and description of the
problem you are going to solve, you give an order to the code base
to fix it, perhaps like:
Update the old-style examples to adjust to the current
practices, with explanations as needed.
To recap, the usual way to compose a log message of this project is
to
- Give an observation on how the current system works in the
present tense (so no need to say "Currently X is Y", or
"Previously X was Y" to describe the state before your change;
just "X is Y" is enough), and discuss what you perceive as a
problem in it.
- Propose a solution (optional---often, problem description
trivially leads to an obvious solution in reader's minds).
- Give commands to the codebase to "become like so".
in this order.
>
> Signed-off-by: K Jayatheerth <jayatheerthkulkarni2005@gmail.com>
> ---
> Documentation/MyFirstContribution.adoc | 20 +++++++++++++++-----
> 1 file changed, 15 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/MyFirstContribution.adoc b/Documentation/MyFirstContribution.adoc
> index ef190d8748..f4320d8869 100644
> --- a/Documentation/MyFirstContribution.adoc
> +++ b/Documentation/MyFirstContribution.adoc
> @@ -142,7 +142,15 @@ command in `builtin/psuh.c`. Create that file, and within it, write the entry
> point for your command in a function matching the style and signature:
>
> ----
> -int cmd_psuh(int argc, const char **argv, const char *prefix)
> +int cmd_psuh(int argc, const char **argv, const char *prefix, struct repository *repo)
> +----
> +
> +We will use the UNUSED macro to make sure we don't recieve compiler warnings
> +for unused arguments from the function cmd_psuh.
> +----
> +int cmd_psuh(int argc UNUSED, const char **argv UNUSED,
> + const char *prefix UNUSED, struct repository *repo UNUSED)
> ----
I do not quite understand. Why do we need a new one here? Wouldn't
it be easier to read for a newcomer if you just give the last one
and explain what UNUSED are for? Perhaps like
... matching the style and signature:
----
int cmd_psuh(int argc UNUSED, const char **argv UNUSED,
const char *prefix UNUSED, struct repository *repo UNUSED)
----
A few things to note:
* A subcommand implementation takes its command line arguments
in `int argc` + `const char **argv`, like `main()` would
* It also takes two extra parameters, `prefix` and `repo`. What
they mean will not be discussed until much later.
* Because this first example will not use any of the parameters,
your compiler will give warnings on unused parameters. As the
list of these four parameters is mandated by the API to add
new built-in commands, you cannot omit them. Instead, you add
`UNUSED` to each of them to tell the compiler that you _know_
you are not (yet) using it.
Take a special note on the last one. There may be multiple ways to
squelch warnings, but it is worth telling your readers that use of
UNUSED is the right way.
I'll stop here for this patch.
Thanks.
next prev parent reply other threads:[~2025-05-17 13:39 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-16 6:14 [PATCH 0/4] update MyFirstContribution with current code base K Jayatheerth
2025-04-16 6:14 ` [PATCH 1/4] Remove unused git-mentoring mailing list K Jayatheerth
2025-04-16 6:14 ` [PATCH 2/4] Docs: Correct cmd_psuh and Explain UNUSED macro K Jayatheerth
2025-05-16 18:08 ` Emily Shaffer
2025-04-16 6:14 ` [PATCH 3/4] Docs: Add cmd_psuh with repo and UNUSED removal K Jayatheerth
2025-05-16 18:12 ` Emily Shaffer
2025-05-16 18:55 ` [PATCH v2 1/3] docs: remove unused mentoring mailing list reference K Jayatheerth
2025-05-16 18:55 ` [PATCH v2 2/3] docs: clarify cmd_psuh signature and explain UNUSED macro K Jayatheerth
2025-05-17 13:39 ` Junio C Hamano [this message]
2025-05-17 18:39 ` Junio C Hamano
2025-05-18 7:34 ` [PATCH v3 0/3] Update MyFirstContribution.adoc to follow modern practices K Jayatheerth
2025-05-18 7:34 ` [PATCH v3 1/3] docs: remove unused mentoring mailing list reference K Jayatheerth
2025-05-18 7:34 ` [PATCH v3 2/3] docs: clarify cmd_psuh signature and explain UNUSED macro K Jayatheerth
2025-05-18 7:34 ` [PATCH v3 3/3] docs: replace git_config to repo_config K Jayatheerth
2025-05-18 7:40 ` JAYATHEERTH K
2025-05-16 18:55 ` [PATCH v2 " K Jayatheerth
2025-05-17 13:39 ` Junio C Hamano
2025-05-16 20:57 ` [PATCH v2 1/3] docs: remove unused mentoring mailing list reference Emily Shaffer
2025-05-17 1:19 ` Junio C Hamano
2025-05-17 3:36 ` [PATCH v3 0/3] Update MyFirstContribution.adoc to follow modern practices K Jayatheerth
2025-05-17 3:36 ` [PATCH v3 1/3] docs: remove unused mentoring mailing list reference K Jayatheerth
2025-05-17 3:36 ` [PATCH v3 2/3] docs: clarify cmd_psuh signature and explain UNUSED macro K Jayatheerth
2025-05-17 3:36 ` [PATCH v3 3/3] docs: replace git_config to repo_config K Jayatheerth
2025-04-16 6:14 ` [PATCH 4/4] cmd_psuh: Prefer repo_config for config lookup K Jayatheerth
2025-05-16 18:26 ` Emily Shaffer
2025-05-16 19:06 ` JAYATHEERTH K
2025-04-16 14:16 ` [PATCH 0/4] update MyFirstContribution with current code base Junio C Hamano
2025-04-16 14:38 ` JAYATHEERTH K
2025-05-13 11:17 ` JAYATHEERTH K
2025-05-14 12:48 ` Junio C Hamano
2025-05-14 13:06 ` JAYATHEERTH K
2025-05-15 22:38 ` Emily Shaffer
2025-05-16 8:20 ` JAYATHEERTH K
2025-05-16 16:11 ` Junio C Hamano
2025-05-16 17:18 ` JAYATHEERTH K
2025-05-20 14:15 ` D. Ben Knoble
2025-05-17 18:24 ` 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=xmqq34d3s6ed.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=jayatheerthkulkarni2005@gmail.com \
--cc=nasamuffin@google.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).