All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Derrick Stolee via GitGitGadget" <gitgitgadget@gmail.com>
To: git@vger.kernel.org
Cc: gitster@pobox.com, Derrick Stolee <stolee@gmail.com>,
	Derrick Stolee <stolee@gmail.com>
Subject: [PATCH] builtin.h: update documentation
Date: Fri, 09 Jan 2026 03:39:01 +0000	[thread overview]
Message-ID: <pull.2028.git.1767929941577.gitgitgadget@gmail.com> (raw)

From: Derrick Stolee <stolee@gmail.com>

The documentation for the builtin API was moved from the technical
documentation and into a comment in builtin.h by ec14d4ecb5 (builtin.h: take
over documentation from api-builtin.txt, 2017-08-02). This documentation
wasn't updated as part of the major overhaul to include a repository struct
in 9b1cb5070f (builtin: add a repository parameter for builtin functions,
2024-09-13).

There was a brief update regarding the move from *.txt to *.adoc by
e8015223c7 (builtin.h: *.txt -> *.adoc fixes, 2025-03-03).

I noticed that there was quite a bit missing from the old documentation,
which is still visible on git-scm.com [1].

[1] https://github.com/git/git-scm.com/issues/2124

This change updates the documentation in the following ways:

 1. Updates the cmd_foo() prototype to include a repository.
 2. Adds some newlines to have uniformity in the list of flags.
 3. Adds a description of the NO_PARSEOPT flag.
 4. Describes the tests that perform checks on all builtins, which may trip
    up a contributor working on a new builtin.

I double-checked these instructions against a toy example in my local branch
to be sure that it was complete.

Signed-off-by: Derrick Stolee <stolee@gmail.com>
---
    builtin.h: update documentation
    
    This is motivated by curiosity and thinking about how to train a new
    contributor on how to create a new builtin. So I found the api-builtin
    docs on the web page and found them grossly out of date, but was glad to
    see some updates in this comment version.
    
    Thanks, -Stolee

Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-2028%2Fderrickstolee%2Fapi-builtin-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-2028/derrickstolee/api-builtin-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/2028

 builtin.h | 26 +++++++++++++++++++++++++-
 1 file changed, 25 insertions(+), 1 deletion(-)

diff --git a/builtin.h b/builtin.h
index 1b35565fbd..e5e16ecaa6 100644
--- a/builtin.h
+++ b/builtin.h
@@ -17,7 +17,8 @@
  * . Define the implementation of the built-in command `foo` with
  *   signature:
  *
- *	int cmd_foo(int argc, const char **argv, const char *prefix);
+ *	int cmd_foo(int argc, const char **argv,
+ *		    const char *prefix, struct repository *repo);
  *
  * . Add the external declaration for the function to `builtin.h`.
  *
@@ -29,12 +30,14 @@
  * where options is the bitwise-or of:
  *
  * `RUN_SETUP`:
+ *
  *	If there is not a Git directory to work on, abort.  If there
  *	is a work tree, chdir to the top of it if the command was
  *	invoked in a subdirectory.  If there is no work tree, no
  *	chdir() is done.
  *
  * `RUN_SETUP_GENTLY`:
+ *
  *	If there is a Git directory, chdir as per RUN_SETUP, otherwise,
  *	don't chdir anywhere.
  *
@@ -57,6 +60,12 @@
  *	more informed decision, e.g., by ignoring `pager.<cmd>` for
  *	certain subcommands.
  *
+ * `NO_PARSEOPT`:
+ *
+ *	Most Git builtins use the parseopt library for parsing options.
+ *	This flag indicates that a custom parser is used and thus the
+ *	builtin would not appear in 'git --list-cmds=parseopt'.
+ *
  * . Add `builtin/foo.o` to `BUILTIN_OBJS` in `Makefile`.
  *
  * Additionally, if `foo` is a new command, there are 4 more things to do:
@@ -69,6 +78,21 @@
  *
  * . Add an entry for `/git-foo` to `.gitignore`.
  *
+ * As you work on implementing your builtin, be mindful that the
+ * following tests will check different aspects of the builtin's
+ * readiness and adherence to matching the documentation:
+ *
+ * * t0012-help.sh checks that the builtin can handle -h, which comes
+ *   automatically with the parseopt API.
+ *
+ * * t0450-txt-doc-vs-help.sh checks that the -h help output matches the
+ *   SYNOPSIS in the documentation for the builtin.
+ *
+ * * t1517-outside-repo.sh checks that the builtin can handle -h when
+ *   run outside of the context of a repository. Note that this test
+ *   requires that the usage has a space after the builtin name, so some
+ *   minimum description of options is required.
+ *
  *
  * How a built-in is called
  * ------------------------

base-commit: d529f3a197364881746f558e5652f0236131eb86
-- 
gitgitgadget

             reply	other threads:[~2026-01-09  3:39 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-09  3:39 Derrick Stolee via GitGitGadget [this message]
2026-01-09 11:37 ` [PATCH] builtin.h: update documentation Pushkar Singh

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=pull.2028.git.1767929941577.gitgitgadget@gmail.com \
    --to=gitgitgadget@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=stolee@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 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.