It looks like any git cmd --help is transformed into "git help --exclude-guides cmd" This is used to differentiate "git cmd --help" and "git help cmd". It's used with aliases to print the alias as well as execute "git help cmd" Maybe something similar can be done for non built-ins that are missing man-pages / html-docs Currently, you may "git-foo --help" directly or use "git foo -h" instead of "git foo --help" but this may be confusing to users On Mon, Dec 20, 2021 at 12:54 PM Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> wrote: > > > On Sat, Dec 18 2021, Sean Allred wrote: > > > Hi folks, > > > > 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? > > > > Best, > > Sean Allred > > > > [1]: https://github.com/git-for-windows/git/discussions/3553 > > I don't know if there's a solution that'll please everyone here, but > it's definitely not narrowing this to built-ins. E.g. "git send-email > --help" will expect to show the manual, so will "git annex --help". -- Erik Cervin-Edin
