The stable branch is about to become even more stable
#13781
comps
announced in
Announcements
Replies: 1 comment
-
|
A small change of plans - the new This is because the current So the new proposed plan is to
This means the last force push to |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Hello,
per the changes proposed in #13769, which are based on my suggestion in #13543 (comment) , we are changing the way the
stablebranch is being managed.Historically, there have been force pushes to it and attempted merges from
master, but the upcoming change (unless other maintainers object) is to have a proper linear history of releases like this:where
A,B, etc. are just merge commits (a.k.a. commits with 2 parents) connecting the releases together. Their tree objects (code contents) are equivalent to the tag connected to the second parent (eg. they always have the same code as the tag).Note that no actual code merging takes place - we are simply manually creating 2-parent commits that serve as a "glue" for the tagged commits.
This, effectively, gives us an always-fast-forwardable history that is never force pushed, with the
stablebranch being usable as a "pointer" to the last released version (because the merge commit has the same tree as the tag).Similarly, this also makes
stabletamper-proof as it's trivial to check that any given merge commit in its history has the same git tree object as the tag in its second parent, so nobody can "sneak in" changes in the merge commits.(After this change is made, the plan is to make
stablea protected branch in the project settings, to avoid accidental force pushes.)For the sake of transparency, the current (2025-08-08) SHA1 of the
stablebranch isc44be6ba82d021945ab81289d803d2a36d2e2221(formerlystabilization-v0.1.77) and the current plan is to do one final force push tostableto replace its history with the scheme outlined above, as part of #13769 being merged.This means
stablewill point to different SHA1, but its contents (verifiable viagit diffagainst the hash above) will be the same.Detailed proof of the new branch being sane
As an example, listing all second parents of all commits on the new
stablebranch would look like this:with the last commit being the oldest release, and thus the first parent of the next-to-last merge:
The tree hashes can then be verified by something like this:
The
newstablebranch was created automatically from the existing tags like this:You probably don't need to care about any of this, I guess we're just showing that the homework was done.
Beta Was this translation helpful? Give feedback.
All reactions