git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: mhagger@alum.mit.edu
Cc: Git Mailing List <git@vger.kernel.org>,
	Junio C Hamano <gitster@pobox.com>,
	dnj@google.com, Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	prohaska@zib.de, john@keeping.me.uk, stanhu@gmail.com,
	richardc@unixbeard.net, Jeff King <peff@peff.net>,
	Joey Hess <id@joeyh.name>
Subject: Re: [RFC/PATCH 0/5] stop installing old libexec aliases like "git-init"
Date: Fri, 16 Nov 2018 20:22:11 +0100	[thread overview]
Message-ID: <87in0w25gc.fsf@evledraar.gmail.com> (raw)
In-Reply-To: <CAMy9T_EVh5Xa7wZFRSM+uGAKV7WSPRALRRaZhPaj_bg9v7Ohfg@mail.gmail.com>


On Fri, Nov 16 2018, Michael Haggerty wrote:

> 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...

  reply	other threads:[~2018-11-16 19:22 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-06 23:34 What's cooking in git.git (Mar 2018, #02; Tue, 6) Junio C Hamano
2018-03-07 12:34 ` Johannes Schindelin
2018-03-08  9:22   ` Ævar Arnfjörð Bjarmason
2018-03-08 13:12     ` Daniel Jacques
2018-03-13 12:36       ` Why don't we symlink libexec/git-core/* to bin/git? Ævar Arnfjörð Bjarmason
2018-03-13 18:36         ` Junio C Hamano
2018-03-13 19:32           ` Randall S. Becker
2018-03-13 20:39           ` [PATCH 0/3] Makefile: add a INSTALL_SYMLINKS option Ævar Arnfjörð Bjarmason
2018-03-13 20:39           ` [PATCH 1/3] Makefile: fix broken bindir_relative variable Ævar Arnfjörð Bjarmason
2018-03-13 20:39           ` [PATCH 2/3] Makefile: add a gitexecdir_relative variable Ævar Arnfjörð Bjarmason
2018-03-13 20:39           ` [PATCH 3/3] Makefile: optionally symlink libexec/git-core binaries to bin/git Ævar Arnfjörð Bjarmason
2018-03-14  7:20             ` Johannes Sixt
2018-03-14 10:14               ` Ævar Arnfjörð Bjarmason
2018-03-14 17:21                 ` Linus Torvalds
2018-03-15 17:05                   ` Johannes Schindelin
2018-03-15 17:42                     ` Linus Torvalds
2018-03-16 11:48                       ` Johannes Schindelin
2018-03-16 12:43                         ` Ævar Arnfjörð Bjarmason
2018-03-19 11:34                           ` Johannes Schindelin
2018-03-19 21:21                             ` Linus Torvalds
2018-11-02 22:37                           ` [RFC/PATCH 0/5] stop installing old libexec aliases like "git-init" Ævar Arnfjörð Bjarmason
2018-11-03  1:17                             ` Junio C Hamano
2018-11-05 11:36                               ` Ævar Arnfjörð Bjarmason
2018-11-12 13:33                             ` Johannes Schindelin
2018-11-16 10:38                             ` Ævar Arnfjörð Bjarmason
2018-11-16 16:00                               ` Michael Haggerty
2018-11-16 19:22                                 ` Ævar Arnfjörð Bjarmason [this message]
2018-11-17  6:39                                   ` Jeff King
2018-11-22 12:48                                     ` Johannes Schindelin
2018-11-22 16:06                                       ` Jeff King
2018-11-23 11:19                                         ` Johannes Schindelin
2018-11-02 22:37                           ` [RFC/PATCH 1/5] Makefile: move long inline shell loops in "install" into helper Ævar Arnfjörð Bjarmason
2018-11-04  1:09                             ` Eric Sunshine
2018-11-12 14:03                             ` Johannes Schindelin
2018-11-12 14:42                               ` Ævar Arnfjörð Bjarmason
2018-11-12 16:32                                 ` Johannes Schindelin
2018-11-16 10:32                                   ` Ævar Arnfjörð Bjarmason
2018-11-02 22:37                           ` [RFC/PATCH 2/5] Makefile: conform some of the code to our coding standards Ævar Arnfjörð Bjarmason
2018-11-02 22:37                           ` [RFC/PATCH 3/5] Makefile: stop hiding failures during "install" Ævar Arnfjörð Bjarmason
2018-11-02 22:37                           ` [RFC/PATCH 4/5] Makefile: add NO_INSTALL_SYMLINKS_FALLBACK switch Ævar Arnfjörð Bjarmason
2018-11-04  1:01                             ` Eric Sunshine
2018-11-02 22:37                           ` [RFC/PATCH 5/5] Makefile: Add a NO_INSTALL_BUILTIN_EXECDIR_ALIASES flag Ævar Arnfjörð Bjarmason
2018-11-04  1:04                             ` Eric Sunshine
2018-11-12 14:14                             ` Johannes Schindelin
2018-03-15 17:03               ` [PATCH 3/3] Makefile: optionally symlink libexec/git-core binaries to bin/git Johannes Schindelin
2018-03-14 10:18         ` Why don't we symlink libexec/git-core/* to bin/git? Ævar Arnfjörð Bjarmason
2018-03-14 16:07           ` Junio C Hamano
2018-03-15 17:16             ` Johannes Schindelin
2018-03-16 17:29               ` Duy Nguyen
2018-03-30  8:59                 ` Johannes Schindelin
2018-03-09  6:15 ` What's cooking in git.git (Mar 2018, #02; Tue, 6) Martin Ågren
2018-03-09  9:54   ` Duy Nguyen
2018-03-09 17:19   ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87in0w25gc.fsf@evledraar.gmail.com \
    --to=avarab@gmail.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=dnj@google.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=id@joeyh.name \
    --cc=john@keeping.me.uk \
    --cc=mhagger@alum.mit.edu \
    --cc=peff@peff.net \
    --cc=prohaska@zib.de \
    --cc=richardc@unixbeard.net \
    --cc=stanhu@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).