git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v2 2/3] docs: clarify cmd_psuh signature and explain UNUSED macro

From
Junio C Hamano <gitster@pobox.com>
Date
May 17, 2025, 13:39 UTC
Message-ID
<xmqq34d3s6ed.fsf@gitster.g>
In-Reply-To
<20250516185516.52311-2-jayatheerthkulkarni2005@gmail.com>
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.
Show 24 quoted lines
>
> 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.
Previous: K JayatheerthNext: Junio C Hamano
Message 9 of 37 in “update MyFirstContribution with current code base”
  1. 0/4 update MyFirstContribution with current code baseK Jayatheerth, Apr 16, 2025
  2. 1/4 Remove unused git-mentoring mailing listK Jayatheerth, Apr 16, 2025
  3. 2/4 Docs: Correct cmd_psuh and Explain UNUSED macroK Jayatheerth, Apr 16, 2025
  4. Emily ShafferMay 16, 2025
  5. 3/4 Docs: Add cmd_psuh with repo and UNUSED removalK Jayatheerth, Apr 16, 2025
  6. Emily ShafferMay 16, 2025
  7. 1/3 docs: remove unused mentoring mailing list referenceK Jayatheerth, May 16, 2025
  8. 2/3 docs: clarify cmd_psuh signature and explain UNUSED macroK Jayatheerth, May 16, 2025
  9. Junio C HamanoMay 17, 2025
  10. Junio C HamanoMay 17, 2025
  11. 0/3 Update MyFirstContribution.adoc to follow modern practicesK Jayatheerth, May 18, 2025
  12. 1/3 docs: remove unused mentoring mailing list referenceK Jayatheerth, May 18, 2025
  13. 2/3 docs: clarify cmd_psuh signature and explain UNUSED macroK Jayatheerth, May 18, 2025
  14. 3/3 docs: replace git_config to repo_configK Jayatheerth, May 18, 2025
  15. JAYATHEERTH KMay 18, 2025
  16. 3/3 docs: replace git_config to repo_configK Jayatheerth, May 16, 2025
  17. Junio C HamanoMay 17, 2025
  18. Emily ShafferMay 16, 2025
  19. Junio C HamanoMay 17, 2025
  20. 0/3 Update MyFirstContribution.adoc to follow modern practicesK Jayatheerth, May 17, 2025
  21. 1/3 docs: remove unused mentoring mailing list referenceK Jayatheerth, May 17, 2025
  22. 2/3 docs: clarify cmd_psuh signature and explain UNUSED macroK Jayatheerth, May 17, 2025
  23. 3/3 docs: replace git_config to repo_configK Jayatheerth, May 17, 2025
  24. 4/4 cmd_psuh: Prefer repo_config for config lookupK Jayatheerth, Apr 16, 2025
  25. Emily ShafferMay 16, 2025
  26. JAYATHEERTH KMay 16, 2025
  27. Junio C HamanoApr 16, 2025
  28. JAYATHEERTH KApr 16, 2025
  29. JAYATHEERTH KMay 13, 2025
  30. Junio C HamanoMay 14, 2025
  31. JAYATHEERTH KMay 14, 2025
  32. Emily ShafferMay 15, 2025
  33. JAYATHEERTH KMay 16, 2025
  34. Junio C HamanoMay 16, 2025
  35. JAYATHEERTH KMay 16, 2025
  36. D. Ben KnobleMay 20, 2025
  37. Junio C HamanoMay 17, 2025

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.