RE: [BUG] Strange git notes completion behaviour

[<rsbecker@nexbridge.com>]

On October 23, 2025 8:49 AM, Jeff King wrote:
>On Wed, Oct 22, 2025 at 10:27:01AM -0400, rsbecker@nexbridge.com wrote:
>
>> I tried running with --no-pager. No difference. Interesting:
>>
>> git show $(git notes list HEAD)
>>
>> works correctly with no error report (from inside gdb), while the run of
>>
>> git --no-pager notes show HEAD
>>
>> still reports:
>> Run till exit from #0  main (argc=5, argv=0x811d000)
>>     at /home/jenkinsbuild/.jenkins/workspace/Git_Pipeline/common-main.c:8
>> Process (0,896) exited with code 037777777764.
>>
>> Is there a path where just an implied return is used? I have seen the optimizer
>> return whatever is in an x86 register - rsx and rsi are both 12 at git.c:982
>> - on occasion.
>
>Not that I know of (and I'd expect the compiler to complain if we ever
>had a code path that didn't return).  It is weird that git-show produces
>the right exit code, but our execvp() of it does not. In your place I
>guess I'd try walking through the debugger all the way down to the exec
>system call (and ideally convincing the debugger to keep going in the
>exec'd process image).

What I found is this:

Git drops into sane_execvp and converts the

git notes show HEAD

to

git show 1aa950256829721750e809788e7b858db79a934a.

When execvp is called, it immediately fails with a -12 - not returned,
just terminates. The -12 is an NonStop-specific execvp error indicating
the process failed because the object is invalid (strange and likely
an artifact rather than a real problem).

When I use the arguments as presented to execvp via bash directly, I get:

error: no note found for object 1aa950256829721750e809788e7b858db79a934a.

and gdb correctly reports

Process (0,709) exited with code 01.

There is no commit with that hash. HEAD is actually 3fc1917e0e69b23265f5c49f90fdb6f4ed98f4a3
so git show is correctly failing. This is Indicating that notes is not invoking git
correctly.