Re: [ANNOUNCE] Git v2.33.0-rc2 (Build/Test Report)

From: Jeff King <peff@peff.net>
Date: Aug 16, 2021, 21:02 UTC
Message-ID: <YRrSXhbaZMLMq+1/@coredump.intra.peff.net>
In-Reply-To: <01c501d792df$5fcb24b0$1f616e10$@nexbridge.com>

On Mon, Aug 16, 2021 at 04:43:25PM -0400, Randall S. Becker wrote:

Show 9 quoted lines

> >Oh. Then the notion from my other mail of "if it's die(), then other tests would presumably see similar failures" might be true. ;)
> 
> When running 
> 
> /home/git/git/t/trash directory.t9001-send-email: git send-email --from="Example <nobody@example.com>" --to=nobody@example.com --smtp-server="/home/git/git/t/trash directory.t9001-send-email/fake.sendmail" --transfer-encoding=8bit 0001-Second.patch longline.patch
> fatal: longline.patch:35 is longer than 998 characters
> warning: no patches were sent
> /home/git/git/t/trash directory.t9001-send-email: echo $?
> 162

Well, that's a promising start to finding the source. :)

> So this is strange. Where is perl run? I'd like to catch the completion inside git.

This will all go through execv_dashed_external() in git.c. So we should just be exiting with the status code we got from the child via wait().

You could try:

  - running it as git-send-email (with a dash), which will exec the perl
    script directly, rather than going through the main git binary

  - instrumenting run-command.c:wait_or_whine() to see how it interprets
    the value. If perl really is returning 255, then perhaps your
    platform's WIFSIGNALED() is confused by that.

If the problem does only show when going through the git binary, then I suspect:

  git -c alias.foo='!perl -e die' foo

may be an easier reproduction.

-Peff