Ludovic Courtès <[email protected]> writes: > Hello, > > Andreas Enge <[email protected]> skribis: > >> Am Fri, Dec 05, 2025 at 09:42:07PM +0100 schrieb Andreas Enge: >>> And given that our current policy is to rebase, I would continue for the >>> time being and also from time to time rebase next-master on master. >> >> not having heard an opposing opinion, I have taken the liberty to rebase >> next-master on master; after Noé has added the branch to the QA queue, >> it is now built out by the bordeaux build farm. (Currently it is only >> 10 commits ahead of master.) > > I like linear histories as well, but rebasing makes it harder to > collaborate (notably, a pull request targeting ‘next-master’ becomes off > once ‘next-master’ is rebased)
I cannot resist the urge to note that in any patch-based system (e.g. gerrit, phabricator, debbugs) this would not be a problem. > and it means that people cannot just run > ‘guix pull --branch=next-master’ unless they ‘--allow-downgrades’, which > is not a reasonable default. Are people actually expected to run next-master, outside of cherry-picking specific packages with inferiors? I know it is actually possible and mentioned in the GCD, but I have to wonder whether people who *would* switch the branch, are also not technical enough to deal with implications of --allow-downgrades. (Personally, current master is close to what I would like Guix to be all the time. Closer to debian than to arch. Though that is a topic for another time.) > > Since ‘next-master’ will be around for about one month IIUC, it might be > best to stop rebasing it. Out of curiosity, how does git-bisect work with merges? Is it still usable to pin-point the offending commits? It is long time since I tried to use it on non-linear history, so I am unsure how well it works these days. Tomas -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors.
