On Fri, Nov 16, 2018 at 11:38 AM Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> wrote: > [...] > A follow-up on this: We should really fix this for other > reasons. I.e. compile in some "this is stuff we ourselves think is in > git". > > There's other manifestations of this, e.g.: > > git-sizer --help # => shows you help > git sizer --help # => says it doesn't have a manpage > > Because we aren't aware that git-sizer is some external tool, and that > we should route --help to it. That would be nice. This has been an annoying for several tools named `git-foo` that I have worked on (e.g., git-sizer, git-imerge, git-when-merged, plus many internal tools). > Non-withstanding the arguable bug that things like git-sizer shouldn't > be allowing themselves to be invoked by "git" like that without > guaranteeing that it can consume all the options 'git' expects. When I > had to deal with a similar problem in an external git-* command I was > maintaining I simply made it an error to invoke it as "git mything" > instead of "git-mything". Hmmm, I always thought that it was intended and supported that an external tool can name itself `git-foo` so that it can be invoked as `git foo`. Which git options do you think that such a tool should be expected to support? Many useful ones, like `-C <path>`, `--git-dir=<path>`, `--work-tree=<path>`, `-c <name>=<value>`, and `--no-replace-objects`, work pretty much for free if the external tool uses `git` to interact with the repository. I use such options regularly with external tools. IMO it would be a regression for these tools to refuse to run when invoked as, say, `git -C path/to/repo foo`. Michael
