Re: [PATCH v2 0/3] nd/clear-gitenv-upon-use-of-alias

[Jeff King <peff@peff.net>]

On Wed, Dec 23, 2015 at 09:37:04PM +0100, Johannes Sixt wrote:

> >--- a/git.c
> >+++ b/git.c
> >@@ -252,7 +252,7 @@ static int handle_alias(int *argcp, const char ***argv)
> >  			alias_argv[argc] = NULL;
> >
> >  			ret = run_command_v_opt(alias_argv, RUN_USING_SHELL);
> >-			if (ret >= 0)   /* normal exit */
> >+			if (ret != -1)  /* normal exit */
> 
> Why does this make a difference? We only ever return -1, zero, or a positive
> value from run_command/finish_command/wait_or_whine, as far as I can see.

Yeah, you're right. This bit predates 709ca73 (run-command: encode
signal death as a positive integer, 2013-01-05), which came out of the
same discussion. So I'd agree this hunk can simply be dropped.

That leaves the ignoring of SIGPIPE in wait_or_whine. I started to
rewrite the commit message to drop the first hunk, but I found I
couldn't replicate the problem in the second either!

Doing:

  GIT_PAGER=false git -c alias.foo='!git log -p' foo

doesn't trigger it. We run the alias through a shell, so we see only the
munged "141" value from the shell's exit code.

Something like:

  GIT_PAGER=false git -p -c alias.foo='!yes' foo

does generate the error message. But we've redirected stderr into the
pager at that point, so by definition it can never be shown.

So I think we would need a case where:

  - the outer git doesn't run the pager that dies; instead the pager is
    run inside the alias. But...

  - inside the alias cannot be a shell pipeline, since "foo | less" will
    report the exit code of "less", not "foo" (we make special arrangements
    in git to propagate the exit code of "foo"). So it pretty much has
    to be a git invocation inside the alias. But...

  - The git invocation will convert signal death in the sub-process into
    141, like a shell would.

So I'm not sure if this is triggerable at all with an alias.

I did manage to trigger it with an external command, like:

  $ cat $(which git-yes)
  #!/bin/sh
  # This _has_ to be exec, otherwise the shell converts SIGPIPE death
  # into 141.
  exec yes

and then if you run your _own_ pager, like this:

  $ git yes | false
  error: git-yes died of signal 13

you see it. But if git starts the pager, you don't:

  $ GIT_PAGER=false git -p yes

Because the stderr of the outer git process is going to the same dead
pipe.

So my takeaways are:

  1. Complaining about signal death in general is going to be flaky,
     because it's so easy for shells or git to rewrite the exit code and
     not trigger WIFSIGNALED() in the first place.

  2. I doubt anybody is actually seeing this in practice anymore. But
     maybe I am misunderstanding something in Duy's series that changes
     this.

-Peff