Proposing a new main branch for the xserver git repo

3 min read Original article ↗
Alan Coopersmith alan.coopersmith at oracle.com
Tue Jan 20 01:38:27 UTC 2026
On IRC last year we discussed the mess in the current master branch of the
xserver repo, with many reverted commits, and other commits preparing for
work which one developer had planned but which will not be coming into our
repo now, and some which quite a few other developers disagreed with.

A proposed way forward was to make a new branch called "main" from a
starting point around Feb. 2024, and to only cherry-pick over from master
the commits which weren't later reverted and which we generally agreed we'd
want to keep.

After doing a bunch of reverts, and then seeing an MR to revert another 40
commits to unbreak the libvnc.so loadable module, I finally sat down to see
what this would look like.

My proposed branch is at:
https://gitlab.freedesktop.org/alanc/xserver/-/tree/main?ref_type=heads
(note that I plan to rewrite/overwrite this branch as necessary while it's
  just in my personal repo and not yet in the main xserver repo)

Diffs of the git shortlog between it and the current master branch are at:
https://gitlab.freedesktop.org/alanc/xserver/-/snippets/7877

Diffs of the full git log between it and the current master branch are at:
https://gitlab.freedesktop.org/alanc/xserver/-/snippets/7878

This main branch has 835 commits since the start point, where the master
branch had 1386 (and that's not counting the 40 reverts from !2102).

I've eliminated commits that met one or more of these:
  - were later reverted, or were the reverts of a commit that was dropped
  - fixed or depended on commits that were dropped
  - didn't follow the license requirements to include copyright & permission
    notices
  - caused a lot of churn for little benefit (like mass replacing the
    PANORAMIX ifdefs with XINERAMA or mass removing HAVE_DIX_CONFIG_H ifdefs)
  - broke ABI/API that we know others used
  - broke long-standing Xserver abstractions/patterns, like function
    vector wrapping/dispatching

I did leave some of the "unexport API" commits that I thought might be safe.

I did not merge fix commits into the commits they fix, so there may still
be some points in the git history that are unbuildable and not good for
git bisects, but there should be fewer than before since the commits we
outright reverted are gone now.

I've not done any testing on this yet besides building and seeing the CI
pipelines all passed, since I'd first like to hear others thoughts on if
this is the right direction and the right subset of commits.

Do we want to make a new main branch and make all future release branches
from it, abandoning the current master branch?  (I hope we can get 26.1
branches of both Xwayland and the other Xservers made this year, after our
25.1 plans for both got scuttled last year by this mess.)

If so, is this the right set of commits to include & exclude?  Now is the
time to rewrite history on this branch before it becomes official and
people start relying on it, if there's more changes we should drop, or
changes I dropped that people think should stay.

-- 
         -Alan Coopersmith-                 alan.coopersmith at oracle.com
          Oracle Solaris Engineering - https://blogs.oracle.com/solaris



More information about the xorg-devel mailing list