Re: Custom subcommand help handlers

From

Johannes Schindelin <johannes.schindelin@gmx.de>

Date

Dec 20, 2021, 22:39 UTC

Message-ID

<nycvar.QRO.7.76.6.2112202324110.347@tvgsbejvaqbjf.bet>

In-Reply-To

<CABceR4ZW4rRWZnH0ZBkWty_H84Z4CmXque_LO+1edETEWrO8PQ@mail.gmail.com>

Hi Sean,

On Sat, 18 Dec 2021, Sean Allred wrote:

> I've got a custom subcommand I'm distributing in my company to integrate
> with our bug-tracker. It's a pretty robust utility and has its own help
> function, but running `git foo --help` doesn't pass --help to my git-foo
> utility. I asked a question[1] about this scenario on the Windows fork
> and they directed me upstream.
>
> It sounds like `git foo --help` is internally consumed as `git help
> foo`, which forwards requests to info/man/web handlers per config.
> Being on Windows and knowing my peers as I do, the vast majority of my
> users won't be familiar with info or man. The HTML documentation used
> by the web handler is in a Git4Win-controlled installation directory
> that I'd really rather not touch/maintain. I really just want `git foo
> --help` to call `git-foo --help`.
>
> What's the best way to go about this?
>
> In the event the best next step is to start a patch, does it sound
> reasonable to simply not perform this `git foo --help` -> `git help
> foo` transformation for non-builtins? Or, while I don't relish the
> idea, would some kind of config option be needed?

-- snip --

diff --git a/git.c b/git.c
index c802dfe98004..d609f90cc117 100644
--- a/git.c
+++ b/git.c
@@ -688,6 +688,33 @@ static void strip_extension(const char **argv)
 #define strip_extension(cmd)
 #endif

+static int is_in_git_exec_path(const char *command_name)
+{
+	struct strbuf path = STRBUF_INIT;
+	int ret = 0;
+
+	if (!command_name)
+		return 0;
+
+	strbuf_addf(&path, "%s/git-%s", git_exec_path(), command_name);
+	ret = !access(path.buf, X_OK);
+
+#ifdef STRIP_EXTENSION
+	if (!ret) {
+		/*
+		 * If `command_name` ended in `.exe`, strip it, otherwise
+		 * append it.
+		 */
+		if (!strbuf_strip_suffix(&path, STRIP_EXTENSION))
+			strbuf_addstr(&path, STRIP_EXTENSION);
+		ret = !access(path.buf, X_OK);
+	}
+#endif
+
+	strbuf_release(&path);
+	return ret;
+}
+
 static void handle_builtin(int argc, const char **argv)
 {
 	struct strvec args = STRVEC_INIT;
@@ -697,8 +724,11 @@ static void handle_builtin(int argc, const char **argv)
 	strip_extension(argv);
 	cmd = argv[0];

+	builtin = get_builtin(cmd);
+
 	/* Turn "git cmd --help" into "git help --exclude-guides cmd" */
-	if (argc > 1 && !strcmp(argv[1], "--help")) {
+	if (argc > 1 && !strcmp(argv[1], "--help") &&
+	    (builtin || is_in_git_exec_path(argv[0]))) {
 		int i;

 		argv[1] = argv[0];
@@ -714,7 +744,6 @@ static void handle_builtin(int argc, const char **argv)
 		argv = args.v;
 	}

-	builtin = get_builtin(cmd);
 	if (builtin)
 		exit(run_builtin(builtin, argc, argv));
 	strvec_clear(&args);
-- snap --

Of course, this might break existing users' setups where they ship a Git
command together with a manual page.

A potential remedy against that would be, as you say, a config option.
Maybe defaulting to the manual page if `help.format` is `man`, otherwise
defaulting to passing `--help` to the command.

Ciao,
Dscho

>
> Best,
> Sean Allred
>
> [1]: https://github.com/git-for-windows/git/discussions/3553
>