All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Jeff King <peff@peff.net>
Cc: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
	mhagger@alum.mit.edu, "Git Mailing List" <git@vger.kernel.org>,
	"Junio C Hamano" <gitster@pobox.com>,
	dnj@google.com, prohaska@zib.de, john@keeping.me.uk,
	stanhu@gmail.com, richardc@unixbeard.net,
	"Joey Hess" <id@joeyh.name>
Subject: Re: [RFC/PATCH 0/5] stop installing old libexec aliases like "git-init"
Date: Thu, 22 Nov 2018 13:48:53 +0100 (STD)	[thread overview]
Message-ID: <nycvar.QRO.7.76.6.1811221344360.41@tvgsbejvaqbjf.bet> (raw)
In-Reply-To: <20181117063940.GA31057@sigill.intra.peff.net>

[-- Attachment #1: Type: text/plain, Size: 3352 bytes --]

Hi Peff,

On Sat, 17 Nov 2018, Jeff King wrote:

> On Fri, Nov 16, 2018 at 08:22:11PM +0100, Ævar Arnfjörð Bjarmason wrote:
> 
> > 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.
> 
> Yeah, I think this really the only problematic assumption. The rest of
> "-c", "--git-dir", etc, are just manipulating the environment, and that
> gets passed through to sub-invocations of Git (so if I have a script
> which calls git-config, it will pick up the "-c" config).
> 
> It would be nice if there was a way to ask "is there a manpage?", and
> fallback to running "git-cmd --help". But:
> 
>   1. I don't think there is a portable way to query that via man. And
>      anyway, depending platform and config, it may be opening a browser
>      to show HTML documentation (or I think even texinfo?).
> 
>   2. We can just ask whether "man git-sizer" (or whatever help display
>      command) returned a non-zero exit code, and fall back to "git-sizer
>      --help". But there's an infinite-loop possibility here: running
>      "git-sizer --help" does what we want. But if "man git-log" failed,
>      we'd run "git-log --help", which in turn runs "git help log", which
>      runs "man git-log", and so on.
> 
>      You can break that loop with an environment variable for "I already
>      tried to show the manpage", which would I guess convert "--help" to
>      "-h".
> 
> So it's maybe do-able, but not quite as trivial as one might hope.

A trivial alternative would be to recommend adding a man page for
3rd-party git-<tool>s.

In other words, as soon as `git-sizer` is accompanied by `git-sizer.1` in
one of the appropriate locations, it is set.

(Actually, it is not: on Windows, it would have to add git-sizer.html in
the appropriate location, but we can deal with this if needed.)

> > 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...
> 
> I think that generally works because hitting ^C is going to send SIGINT
> to the whole process group. A more interesting case is:
> 
>   git sigint &
>   kill -INT $!
> 
> There $! is a parent "git" process that is just waiting on git-sigint to
> die. But that works, too, because the parent relays common signals due
> to 10c6cddd92 (dashed externals: kill children on exit, 2012-01-08). So
> you might have been remembering issues prior to that commit (or uncommon
> signals; these come from sigchain_push_common).

FWIW I do have a couple of scripts I use that I install into
`$HOME/bin/git-<tool>`. Although, granted, I essentially switched to
aliases for most of them, where the aliases still call a script that is
checked out in some folder in my home directory. The reason: this works in
more circumstances, as I do not have to add `$HOME/bin` to the `PATH`,
say, in PowerShell.

So YMMV with git-<tool>s. My rule of thumb is: if I want to use this
myself only, I'll make it an alias. If I want to ship it (e.g. with Git
for Windows), I'll make it a git-<tool>.

Ciao,
Dscho

  reply	other threads:[~2018-11-22 12:49 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
2018-11-17  6:39                                   ` Jeff King
2018-11-22 12:48                                     ` Johannes Schindelin [this message]
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

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

  git send-email \
    --in-reply-to=nycvar.QRO.7.76.6.1811221344360.41@tvgsbejvaqbjf.bet \
    --to=johannes.schindelin@gmx.de \
    --cc=avarab@gmail.com \
    --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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.