Re: Custom subcommand help handlers
- From
Johannes Schindelin <johannes.schindelin@gmx.de>
- Date
- Dec 22, 2021, 16:16 UTC
- Message-ID
- <nycvar.QRO.7.76.6.2112221640340.347@tvgsbejvaqbjf.bet>
- In-Reply-To
- <211221.86k0fysm0i.gmgdl@evledraar.gmail.com>
Hi Ævar,
On Tue, 21 Dec 2021, Ævar Arnfjörð Bjarmason wrote:
Show 30 quoted lines
> On Mon, Dec 20 2021, Johannes Schindelin wrote: > > > 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. [...] > >> > >> What's the best way to go about this? > > > > I think you might need to be a bit more careful than just looking whether > > the command in question is a built-in or not. It could be delivered as a > > script or executable inside `libexec/git-core`. So maybe check that, > > something like this: > > > > -- snip -- > > [...] > > -- 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. > > What are the cases that require us to inexpect our --exec-path at > runtime, as opposed to having a list of commands we know we put there at > "install" time?
It is a simple solution. Why even suggest a complex alternative, I wonder.
Ciao, Johannes