Am Tue, Dec 09, 2025 at 12:16:31AM +0100 schrieb Tomas Volf: > > 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.
That was my argument; running next-master is also not a reasonable default. Anyway "guix pull" defaults to master, so people who pull to something else can be expected to have enough technical knowledge to move over to something else with potentially a "down"-grade. > > 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. This is another question I had, which is not necessarily related to next-master. Maybe people should all the time declare their pull requests as relative to master? There is this annoyance of a team branch that once it is merged and deleted causes all other pull requests to this branch to be closed. Since anyway we do not merge with the push of a button, but committers effectively cherry-pick the single commits, are we not already in this patch based workflow? Andreas
