git/list[1] front-page[2] threads[3] people[4] search[5] about
 

RE: [BUG] Strange git notes completion behaviour

From
rsbecker@nexbridge.com <rsbecker@nexbridge.com>
Date
Oct 24, 2025, 17:33 UTC
Message-ID
<029a01dc450c$4318dfe0$c94a9fa0$@nexbridge.com>
In-Reply-To
<20251023124837.GB1163932@coredump.intra.peff.net>
On October 23, 2025 8:49 AM, Jeff King wrote:
Show 25 quoted lines
>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.

Previous: Jeff KingNext: Jeff King
Message 7 of 12 in “[BUG] Strange git notes completion behaviour”
  1. rsbecker@nexbridge.comOct 21, 2025
  2. D. Ben KnobleOct 21, 2025
  3. rsbecker@nexbridge.comOct 21, 2025
  4. Jeff KingOct 22, 2025
  5. rsbecker@nexbridge.comOct 22, 2025
  6. Jeff KingOct 23, 2025
  7. rsbecker@nexbridge.comOct 24, 2025
  8. Jeff KingOct 24, 2025
  9. rsbecker@nexbridge.comOct 24, 2025
  10. Jeff KingOct 24, 2025
  11. rsbecker@nexbridge.comOct 24, 2025
  12. Jeff KingOct 24, 2025

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.