The Lilliput main repository is maintained in a way such that the Lilliput-specific changes are always 'on top' of the JDK mainline changes. For example, at the time of writing, we maintain 4 changes, and it looks like this (O are random upstream changes, A..D are the Lilliput changes:

O--O--O--A--B--C--D

When merging from upstream, we get more changes on the mainline branch:

O--O--O--A--B--C--D
       \-O--O--O--O

And we merge them with the Lilliput changes, such that we replace them with the upstream changes (-s ours option of the git merge command). The result looks like this (M is the merge changeset):

O--O--O--A--B--C--D--M
       \-O--O--O--O-/

At this point, the state of the working directory would be 100% identical to the upstream that we just merge. Now we only need to transplant the Lilliput changes to the top again. I call them A'..D' to indicate that those changes are not exactly the same as A..D, the new changeset might require adjustments, sometimes even significant reworks, in order to deal with new upstream changes.

O--O--O--A--B--C--D--M--A'--B'--C'--D'
       \-O--O--O--O-/

The exact procedure for merging looks like follows:

# Make sure you are on the latest lilliput master branch
git fetch lilliput-main master
git checkout master
git merge lilliput-main master

# Fetch upstream jdk changes
git fetch jdk-upstream

# Create a branch that we are going to use to merge the upstream tag jdk-26+26.
# Notice that we create the branch from the jdk-26+26 tag - this will *not* have
# any Lillput changes.
git checkout -b merge-jdk-26+26 jdk-26+26

# Now we merge in the Lilliput master branch into our working branch,
# but we pick 'ours' for any changes, which means that the end result
# will still look exactly like jdk-26+26 with no Lilliput changes.
git merge -s ours master

# And now we transplant the Lilliput-changes one-by-one: