Re: [RFC/PATCH 0/5] stop installing old libexec aliases like "git-init"

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Nov 16, 2018, 19:22 UTC
Message-ID: <87in0w25gc.fsf@evledraar.gmail.com>
In-Reply-To: <CAMy9T_EVh5Xa7wZFRSM+uGAKV7WSPRALRRaZhPaj_bg9v7Ohfg@mail.gmail.com>

On Fri, Nov 16 2018, Michael Haggerty wrote:

Show 37 quoted lines

> On Fri, Nov 16, 2018 at 11:38 AM Ævar Arnfjörð Bjarmason
> <avarab@gmail.com> 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`.

I don't mean we should forbid it, just that if you have an external git-foo tool meant to be invoked like "git-foo" that and not "git foo" it might be worth to save yourself the trouble and not support the latter. I thought git-sizer was one such tool, since it docs just mention "git-sizer".

But yeah, "-c" etc. are useful, and we definitely want to support this in the general case. E.g. for "git-annex" and others that are meant to be used like that.

So maybe we should just document this interface better. It seems one implicit dependency is that we expect a manpage for the tool to exist for --help.

Or, keep some list of internal git tools and treat them specially. But I see now that would break "git annex --help" in the other direction, but maybe that would be better. I don't know.

As I recall I stopped supporting "git" invocation for the tool I was fixing a long time ago because of some funny interaction with terminals & signals. I.e. git itself would eat some of them, but the tool wanted to handle it instead.

But I don't remember the details, and can't reproduce it now with:

    $ cat ~/bin/git-sigint 
    #!/usr/bin/env perl
    $SIG{INT} = sub { warn localtime . " " . $$ };
    sleep 1 while 1;
    $ git sigint # or git-sigint
    [... behaves the same either way ...]

So maybe it was something else, or I'm misremembering...