Re: [PATCH v2 08/12] submodule--helper: report "submodule" as our name in "-h" output

From: Glen Choo <chooglen@google.com>
Date: Jun 15, 2022, 03:34 UTC
Message-ID: <kl6lfsk661mr.fsf@chooglen-macbookpro.roam.corp.google.com>
In-Reply-To: <patch-v2-08.12-99ac52d810f-20220613T220150Z-avarab@gmail.com>

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

Show 12 quoted lines

> Change the rest of the usage output for "git submodule--helper" so
> that it will pretend to be named "git submodule", which it already did
> e.g. in the case of "status", "deinit" and "update".
>
> This will allow us to eventually dispatch further into "git
> submodule--helper" from git-submodule.sh, while emitting the correct
> usage output.
>
> This does make the usage output of "git submodule--helper" itself
> "incorrect", but since nothing user-facing invokes it directly it
> makes sense to continue to elide that difference entirely. A user
> isn't served by us exposing this internal implementation detail.

Everything up to here makes sense. I agree that "git submodule--helper" should have been pretending to be "git submodule" wherever possible.

Before now, it probably didn't matter much because it's quite hard to get "git submodule--helper" to print usage without being first intercepted by "git submodule", but we'll need it now. Which brings us to..

Show 8 quoted lines

> This fixes a bug that's been there ever since "git submodule
> absorbgitdirs" was added in f6f85861400 (submodule: add absorb-git-dir
> function, 2016-12-12). Before this we'd emit e.g. this on invalid
> usage:
>
> 	$ git submodule absorbgitdirs --blah
> 	error: unknown option `blah'
> 	usage: git submodule--helper absorbgitdirs [<options>] [<path>...]

We actually used to output the internal-only name of the submodule--helper subcommand, i.e.

  git submodule--helper absorb-git-dirs

with the dashes.

Show 5 quoted lines

> Now we'll emit the same, except that the usage line is now referring
> to the correct command run by the user:
>
> 	usage: git submodule absorbgitdirs [<options>] [<path>...]
> 	[.. same usage output ...]

I initially wondered why "absorbgitdirs" deserved a special shoutout when we are changing several other subcommands in the same patch, but it turns out that this usage string bug probably is "absorbgitdirs"-specific.

"absorbgitdirs" is the only subcommand that doesn't have an options parsing loop that catches invalid options, it's just:

  cmd_absorbgitdirs()
  {
    git submodule--helper absorb-git-dirs --prefix "$wt_prefix" "$@"
  }

whereas in other subcommands, invalid usage would be caught by by the options parsing loop and we never invoke "git submodule--helper blah". As a result, "git submodule--helper absorb-git-dirs" is probably the only subcommand that prints its usage string (instead of the generic "git submodule" usage string.)

It might be worth highlighting how absorbgitdirs is special in the commit message, but I don't feel strongly either way.