patcht0213: skip ancestry tests under user-mode emulation

7 messages between Jul 6, 2026 and Aug 3, 2026, from Jamie Magee via GitGitGadget, Junio C Hamano, Weijie Yuan.

Plain Markdown or JSON for tools and agents. Diffs are folded; open one to read it.

Jamie Magee via GitGitGadgetJul 6, 2026, 17:34 UTC on lore

From: Jamie Magee <jamie.magee@gmail.com>

The tests added in 3c8c638df6 (t0213: add trace2 cmd_ancestry tests, 2026-02-13) expect the cmd_ancestry event to name "test-tool" and "git". On Linux those names come from the "comm" field of /proc/<pid>/stat. Under user-mode emulation (e.g. qemu-user) /proc reports the emulator ("qemu-riscv64") instead, so the event is still emitted, the TRACE2_ANCESTRY probe enables the tests, and tests 2-5 fail even though they pass on native riscv64.

Require the probe to see "test-tool" in the ancestry of a test-tool spawned from test-tool, so the tests skip when the names are unreliable.

Cc: Matthew John Cheetham <mjcheetham@outlook.com>
Signed-off-by: Jamie Magee <jamie.magee@gmail.com>
---
    t0213: skip ancestry tests under user-mode emulation

Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-2168%2FJamieMagee%2Ft0213-skip-under-emulation-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-2168/JamieMagee/t0213-skip-under-emulation-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/2168

 t/t0213-trace2-ancestry.sh | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

Show changes to t/t0213-trace2-ancestry.sh +6 −3

diff --git a/t/t0213-trace2-ancestry.sh b/t/t0213-trace2-ancestry.sh
index a2b9536da8..2eb86c1952 100755
--- a/t/t0213-trace2-ancestry.sh
+++ b/t/t0213-trace2-ancestry.sh
@@ -31,12 +31,15 @@ PATH="$TTDIR:$PATH" && export PATH
 # no cmd_ancestry event is emitted.  We detect this at runtime and
 # skip the format-specific tests accordingly.
 
-# Determine if cmd_ancestry is supported on this platform.
+# Enable these tests only when cmd_ancestry reports real process names.
+# The procinfo stub emits no event; under user-mode emulation (e.g.
+# qemu-user) /proc reports the emulator, not the guest. Spawn test-tool
+# from test-tool and require "test-tool" in the child's ancestry.
 test_expect_success 'detect cmd_ancestry support' '
 	test_when_finished "rm -f trace.detect" &&
 	GIT_TRACE2_BRIEF=1 GIT_TRACE2="$(pwd)/trace.detect" \
-		test-tool trace2 001return 0 &&
-	if grep -q "^cmd_ancestry" trace.detect
+		test-tool trace2 004child test-tool trace2 001return 0 &&
+	if grep -q "^cmd_ancestry.*test-tool" trace.detect
 	then
 		test_set_prereq TRACE2_ANCESTRY
 	fi

base-commit: e9019fcafe0040228b8631c30f97ae1adb61bcdc

-- 
gitgitgadget

Junio C HamanoJul 7, 2026, 02:30 UTC in reply to Jamie Magee via GitGitGadget on lore

Re: [PATCH] t0213: skip ancestry tests under user-mode emulation

"Jamie Magee via GitGitGadget" <gitgitgadget@gmail.com> writes:

Show 5 quoted lines

> -# Determine if cmd_ancestry is supported on this platform.
> +# Enable these tests only when cmd_ancestry reports real process names.
> +# The procinfo stub emits no event; under user-mode emulation (e.g.
> +# qemu-user) /proc reports the emulator, not the guest. Spawn test-tool
> +# from test-tool and require "test-tool" in the child's ancestry.

T.r.i.c.k.y. ;-)

Show 7 quoted lines

>  test_expect_success 'detect cmd_ancestry support' '
>  	test_when_finished "rm -f trace.detect" &&
>  	GIT_TRACE2_BRIEF=1 GIT_TRACE2="$(pwd)/trace.detect" \
> -		test-tool trace2 001return 0 &&
> -	if grep -q "^cmd_ancestry" trace.detect
> +		test-tool trace2 004child test-tool trace2 001return 0 &&
> +	if grep -q "^cmd_ancestry.*test-tool" trace.detect

This will be happy even if "test-tool-trash" that happens to have "test-tool" as its prefix appears on a cmd_ancestry line (for that matter, things like "cmd_ancestry-not-quite" that has "cmd_ancestry" as its prefix would be accepted). I guess that is OK because we are testing this in a fairly tightly controlled environment (trace keys are taken from known vocabulary, not arbitrary strings, for example).

Will queue.  Thanks.

Show 5 quoted lines

>  	then
>  		test_set_prereq TRACE2_ANCESTRY
>  	fi
>
> base-commit: e9019fcafe0040228b8631c30f97ae1adb61bcdc

Junio C HamanoJul 21, 2026, 17:17 UTC in reply to Junio C Hamano on lore

Re: [PATCH] t0213: skip ancestry tests under user-mode emulation

Junio C Hamano <gitster@pobox.com> writes:

Show 26 quoted lines

> "Jamie Magee via GitGitGadget" <gitgitgadget@gmail.com> writes:
>
>> -# Determine if cmd_ancestry is supported on this platform.
>> +# Enable these tests only when cmd_ancestry reports real process names.
>> +# The procinfo stub emits no event; under user-mode emulation (e.g.
>> +# qemu-user) /proc reports the emulator, not the guest. Spawn test-tool
>> +# from test-tool and require "test-tool" in the child's ancestry.
>
> T.r.i.c.k.y. ;-)
>
>>  test_expect_success 'detect cmd_ancestry support' '
>>  	test_when_finished "rm -f trace.detect" &&
>>  	GIT_TRACE2_BRIEF=1 GIT_TRACE2="$(pwd)/trace.detect" \
>> -		test-tool trace2 001return 0 &&
>> -	if grep -q "^cmd_ancestry" trace.detect
>> +		test-tool trace2 004child test-tool trace2 001return 0 &&
>> +	if grep -q "^cmd_ancestry.*test-tool" trace.detect
>
> This will be happy even if "test-tool-trash" that happens to have
> "test-tool" as its prefix appears on a cmd_ancestry line (for that
> matter, things like "cmd_ancestry-not-quite" that has "cmd_ancestry"
> as its prefix would be accepted).  I guess that is OK because we are
> testing this in a fairly tightly controlled environment (trace keys
> are taken from known vocabulary, not arbitrary strings, for example).
>
> Will queue.  Thanks.

Just to clarify, 'Will queue' simply means that the patch will appear in 'seen'. It does not imply that I have personally reviewed the change and found it acceptable to merge into 'next'.

I would appreciate a review from someone familiar with the trace2 facility.

Thanks.

Weijie YuanJul 21, 2026, 18:06 UTC in reply to Jamie Magee via GitGitGadget on lore

Re: [PATCH] t0213: skip ancestry tests under user-mode emulation

On Mon, Jul 06, 2026 at 05:34:01PM +0000, Jamie Magee via GitGitGadget wrote:

Show 16 quoted lines

> From: Jamie Magee <jamie.magee@gmail.com>
> 
> The tests added in 3c8c638df6 (t0213: add trace2 cmd_ancestry tests,
> 2026-02-13) expect the cmd_ancestry event to name "test-tool" and
> "git". On Linux those names come from the "comm" field of
> /proc/<pid>/stat. Under user-mode emulation (e.g. qemu-user) /proc
> reports the emulator ("qemu-riscv64") instead, so the event is still
> emitted, the TRACE2_ANCESTRY probe enables the tests, and tests 2-5
> fail even though they pass on native riscv64.
> 
> Require the probe to see "test-tool" in the ancestry of a test-tool
> spawned from test-tool, so the tests skip when the names are unreliable.
> 
> Cc: Matthew John Cheetham <mjcheetham@outlook.com>
> Signed-off-by: Jamie Magee <jamie.magee@gmail.com>
> ---

Very sorry to say something completely outside the patch.

But may I ask what's the point of writting the line started with "Cc:"? I know that Linux kernel has something about writting Cc in the commit message, while I don't see much from Git's documentation about trailers, including MyFirstContribution and SubmittingPatches. Although I know that "git send-email" and "git interpret-trailers" could use "Cc:", I still wonder whether using this trailer is encouraged or not. If so, adding some decriptions about it would be nice, I guess, since I was confused when reading kernel docs about using Cc trailers in the commit message sometime ago.

Sorry in advance if I missed any context.

Thanks very much.

Junio C HamanoJul 21, 2026, 21:55 UTC in reply to Weijie Yuan on lore

Re: [PATCH] t0213: skip ancestry tests under user-mode emulation

Weijie Yuan <wy@wyuan.org> writes:

Show 12 quoted lines

>> ...
>> Cc: Matthew John Cheetham <mjcheetham@outlook.com>
>> Signed-off-by: Jamie Magee <jamie.magee@gmail.com>
>> ---
>
> Very sorry to say something completely outside the patch.
>
> But may I ask what's the point of writting the line started with "Cc:"?
> ...
> I know that Linux kernel has something about writting Cc in the commit
> message, while I don't see much from Git's documentation about trailers,
> including MyFirstContribution and SubmittingPatches.

If you ask me, 'Cc:' belongs in e-mail headers, not in commit messages, though the Linux kernel community has a different convention.

GitGitGadget collects 'Cc:' lines from the commit message and, when sending e-mails on behalf of the author, copies the recipients listed there, if I am not mistaken. Thus, it is not surprising that contributors use the trailer for that purpose.

We do not use the 'Cc:' trailer to allow a commit author to say, "As the commit object indicates, I CC'd this change to that expert. I am no longer solely responsible for any bugs in this commit. That expert should have caught my mistake!" ;-)

Thanks.

Weijie YuanJul 22, 2026, 06:27 UTC in reply to Junio C Hamano on lore

Re: [PATCH] t0213: skip ancestry tests under user-mode emulation

On Tue, Jul 21, 2026 at 02:55:44PM -0700, Junio C Hamano wrote:

Show 23 quoted lines

> Weijie Yuan <wy@wyuan.org> writes:
> 
> >> ...
> >> Cc: Matthew John Cheetham <mjcheetham@outlook.com>
> >> Signed-off-by: Jamie Magee <jamie.magee@gmail.com>
> >> ---
> >
> > Very sorry to say something completely outside the patch.
> >
> > But may I ask what's the point of writting the line started with "Cc:"?
> > ...
> > I know that Linux kernel has something about writting Cc in the commit
> > message, while I don't see much from Git's documentation about trailers,
> > including MyFirstContribution and SubmittingPatches.
> 
> If you ask me, 'Cc:' belongs in e-mail headers, not in commit
> messages, though the Linux kernel community has a different
> convention.
> 
> GitGitGadget collects 'Cc:' lines from the commit message and, when
> sending e-mails on behalf of the author, copies the recipients
> listed there, if I am not mistaken.  Thus, it is not surprising that
> contributors use the trailer for that purpose.

Yeah, I noticed that this patch was sent bt GGG. But since he has already added "Cc" at the end of the commit message, yet in the actual email header, there is no "Matthew John Cheetham", which was confusing? This is something I forgot to mention in the previous email, sorry.

I may have to take a closer look at GGG later.

> We do not use the 'Cc:' trailer to allow a commit author to say, "As
> the commit object indicates, I CC'd this change to that expert.  I
> am no longer solely responsible for any bugs in this commit.  That
> expert should have caught my mistake!"  ;-)

;-) I agree!

Thanks!

Junio C HamanoAug 3, 2026, 20:59 UTC in reply to Jamie Magee via GitGitGadget on lore

Re: [PATCH] t0213: skip ancestry tests under user-mode emulation

"Jamie Magee via GitGitGadget" <gitgitgadget@gmail.com> writes:

Show 17 quoted lines

> From: Jamie Magee <jamie.magee@gmail.com>
>
> The tests added in 3c8c638df6 (t0213: add trace2 cmd_ancestry tests,
> 2026-02-13) expect the cmd_ancestry event to name "test-tool" and
> "git". On Linux those names come from the "comm" field of
> /proc/<pid>/stat. Under user-mode emulation (e.g. qemu-user) /proc
> reports the emulator ("qemu-riscv64") instead, so the event is still
> emitted, the TRACE2_ANCESTRY probe enables the tests, and tests 2-5
> fail even though they pass on native riscv64.
>
> Require the probe to see "test-tool" in the ancestry of a test-tool
> spawned from test-tool, so the tests skip when the names are unreliable.
>
> Cc: Matthew John Cheetham <mjcheetham@outlook.com>
> Signed-off-by: Jamie Magee <jamie.magee@gmail.com>
> ---
>     t0213: skip ancestry tests under user-mode emulation

While nobody with similar environment that would benefit from this change has stepped up since this patch was posted almost a month ago (and I do not have such an environment to test it on, either), this seems low impact enough to cause regressions in environments where the change does not intend to affect (i.e., native environments where process names are trustworthy).

So I am tempted to merge this down, only if it is to shrink the number of in-flight topics I have to carry and watch out for updates, as nobody seems to be motivated enough to recruit testers or reviewers to move the topic forward.

Those who are not in the user-mode emulation environment and are negatively affected because this patch drops TRACE2_ANCESTRY from your envionment should block me with a real review on the patch, preferrably with suggested improvements.

Thanks.