This does seem like the right way forward, and I'd love to see us using current norms for branch names. In particular, changing how screen wrapping worked without being an expert in the first place was solid "oh, this branch has been trashed" evidence for me.
I wont have time to review your commit subset in the next week at least, but I do trust your judgement. On Mon, Jan 19, 2026, 5:38 PM Alan Coopersmith <[email protected]> wrote: > 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- [email protected] > Oracle Solaris Engineering - https://blogs.oracle.com/solaris > >
