Re: git does not wait on hook exes (^C)
- From
Anthony Sottile <asottile@umich.edu>
- Date
- Feb 21, 2020, 00:12 UTC
- Message-ID
- <CA+dzEBkP==U7iS=6vS4=g7LYwh_cKzqbPApDraiYv7tiwPOVHA@mail.gmail.com>
- In-Reply-To
- <20200221000141.GA6462@camp.crustytoothpaste.net>
On Thu, Feb 20, 2020 at 4:01 PM brian m. carlson <sandals@crustytoothpaste.net> wrote:
Show 47 quoted lines
>
> On 2020-02-20 at 21:14:55, Anthony Sottile wrote:
> > Here's a small example:
> >
> > ```bash
> > #!/usr/bin/env bash
> > foo() {
> > echo zzz part 2
> > sleep 1
> > echo exiting now
> > }
> > trap foo SIGINT
> >
> > echo zzz part 1
> > sleep 10
> > ```
> >
> > ```console
> > $ git --version
> > git version 2.25.GIT
> > $ git commit --allow-empty -m foo
> > zzz part 1
> > ^Czzz part 2
> >
> > $ exiting now
> > ```
> >
> > - I pressed ^C during the first sleep
> > - control was returned back to my terminal
> > - the hook script was still running in the background
>
> I believe the way that SIGINT works on a terminal is that it sends the
> signal to all processes in the foreground process group. So my guess of
> what's happening here is that Git and your script both get SIGINT, Git
> cleans up and exits quickly, leaving your script running.
>
> If so, I'm not sure that Git can do much here. If Git waited for the
> hook to exit, then a broken or hung hook would cause Git to hang
> indefinitely, which is not what the user intended when they pressed
> Ctrl-C. Usually what the user wants is an immediate return to the
> terminal in such a case, and I think most users would consider it a bug
> if Git were to wait for its children.
>
> Certainly I'm open to hearing other views on this, though.
> --
> brian m. carlson: Houston, Texas, US
> OpenPGP: https://keybase.io/bk2204Taking git out of the situation:
Create a shell script:
```bash #!/usr/bin/env bash .git/hooks/pre-commit ```
```console $ ./t.sh zzz part 1 ^Czzz part 2 exiting $ ```
that works fine (and is the expected case for `subprocess` calls for example in python)
Anthony