Rolling stable kernels

Posted Oct 7, 2021 5:25 UTC (Thu) by marcH (subscriber, #57642)
Parent article: Rolling stable kernels

> The idea is to use "Git magic" to make it all work; there is no cherry picking of patches. Instead a "hack on Git merges" is used, which preserves the SHA1 values as they are in the existing stable branches

This seems to be the crux of the proposal but I didn't see any explanation of what this "hack" is... did I miss anything?

Rolling stable kernels

Posted Oct 7, 2021 12:43 UTC (Thu) by cwhitecrowdstrike (guest, #153291) [Link]

I wondered the same. I looked online, but the video doesn't appear to be on YouTube yet, and I can't find the slides (if there are any). Could anyone who attended post whatever details you may have? Thanks!

Rolling stable kernels

Posted Oct 7, 2021 12:49 UTC (Thu) by pbonzini (subscriber, #60935) [Link] (6 responses)

Let's say the latest stable release is 5.14.9 and 5.15.1 comes out. The content of rolling-stable is 5.14.9, but when you do

git merge -n 5.15.1        # fails with horrible conflicts
git restore -s 5.15.1 .    # some of you may know this as "git checkout 5.15.1 -- ."
git commit -m'advance rolling stable-tree to 5.15.1'

... it becomes exactly the same as 5.15.1 and can be fast-forwarded from 5.14.9 to 5.15.1. Of course this works because 5.14.10 will never be merged into the rolling-stable tree.

Rolling stable kernels

Posted Oct 7, 2021 21:57 UTC (Thu) by ibukanov (subscriber, #3942) [Link] (1 responses)

How can it be the same as 5.15.1 if the commit message are different? Surely the tree sha stay the same, but sha of the commit that is derived both from the tree and the message will be different.

Plus git commit-tree allows to perform the above manipulation without any merge or conflicts.

Rolling stable kernels

Posted Oct 8, 2021 7:11 UTC (Fri) by pbonzini (subscriber, #60935) [Link]

Of course the commits are different. In "it becomes the same as 5.15.1", "it" refers to "the content of rolling-stable" from the previous sentence.

Rolling stable kernels

Posted Oct 8, 2021 0:18 UTC (Fri) by amboar (subscriber, #55307) [Link] (3 responses)

Playing git-golf a bit here, but this can be done in one operation with `git merge -s ours 5.15.1`. As I was reading the article I thought it sounded awfully similar to something I blogged recently: https://amboar.github.io/notes/2021/09/16/history-preserv...

Rolling stable kernels

Posted Oct 8, 2021 0:28 UTC (Fri) by amboar (subscriber, #55307) [Link] (2 responses)

Ugh, that should have been the other way around with respect to the branch state and merged tag, but the important bit was the existence of the "ours" merge strategy :)

Rolling stable kernels

Posted Oct 8, 2021 7:12 UTC (Fri) by pbonzini (subscriber, #60935) [Link] (1 responses)

Yes, exactly. What one would need here is a "theirs" merge strategy, but it doesn't exist.

Rolling stable kernels

Posted Mar 29, 2023 19:34 UTC (Wed) by tsaeger (subscriber, #116881) [Link]

I git-golf from time-to-time :)

# git merge -s "theirs"
THEIRS=v5.15.1
git merge -s ours --no-commit "${THEIRS}"
git read-tree -u --reset "${THEIRS}"
git commit --no-edit