CODEWITHSUNDEEP
gitlinux-kernel
pjnozisk
pjnozisk

Reputation: 1

kernel.org stable Git : patch reachable from v5.11 but not v5.10-rcX

I’ve run into a Git phenomenon the kernel.org stable repo that I can’t quite explain:

There’s a specific patch I’m curious about (commit ID below) that isn’t reachable from where I’d expect it to be :

$ git describe 2224fc9efb2d6593fbfb57287e39ba4958b188ba
v5.10-rc3-262-g2224fc9efb2d  #  ( upstreamed bewteen v5.10-rc3 and v5.10-rc4)

But now, I see:

$ git log --no-merges --oneline v5.10-rc3..master | grep 2224fc9efb2d
2224fc9efb2d KVM: x86: Expose AVX512_FP16 for supported CPUID
$ git log --no-merges --oneline v5.10-rc3..v5.10-rc4 | grep 2224fc9efb2d 
$ git log --no-merges --oneline v5.10-rc3..v5.10 | grep 2224fc9efb2d
$ git log --no-merges --oneline v5.10-rc3..v5.11 | grep 2224fc9efb2d
2224fc9efb2d KVM: x86: Expose AVX512_FP16 for supported CPUID

QUESTION: Why would that patch be unreachable* from the next RC tag, and unreachable from v5.10, but reachable from v5.11.X, and from master? What was likely done to hide the patch from v5.10-rc4 through v5.10.X ?

Upvotes: 0

Views: 96

Answers (1)

Obsidian
Obsidian

Reputation: 3897

QUESTION: Why would that patch be unreachable* from the next RC tag, and unreachable from v5.10, but reachable from v5.11.X, and from master?

Simply because this commit lies on a branch that was born from a fork that occurred a little while after v5.10-rc3 (which explains why this is the first annotated tag git describe can fetch from it), but merged back in the main Linus's line a LONG time after this moment. It was not easy to find but it seems that this branch was merged with commit 6a447b0e3151893f6d4a889956553c06d2e775c6 (from Linus, December 20th of 2020).

We can also observe that this merge operation occurred exactly between v5.10 and v5.11-rc1, which is perfectly normal and expected: each time a new kernel is released, follows a 2-weeks merging window meant to incorporate all the branches the different maintainers prepared so far. Once these 2 weeks are done, merging is stopped and so begin the stabilization phasis, which will lead to different release candidates named -rc1 to -rcx (usually 7 or 8), then the kernel is considered stable and a new version is released in turn.

What was likely done to hide the patch from v5.10-rc4 through v5.10.X ?

No, that's just because (as explained above), once the first -rc1 is published, no additional contribution is longer allowed in the kernel, which usually causes a lot of stress to the developers, because either they manage to ship them on time, or this will be for the next kernel (which usually means 10 weeks later). On the other hand, maintainers keep telling people that it's OK if it's not integrated first. What we want is something deeply tested and stable (some people ships modifications they never had run themselves).

You can try:

git log --graph 2224fc9efb2d6593fbfb57287e39ba4958b188ba^..6a447b0e3151893f6d4a889956553c06d2e775c6

… to retrieve it more easily. I also recommend you to use a git browser such as tig to navigate through your history.

Upvotes: 1

Related Questions