Hugo Buddelmeijer via "Development of GNU Guix and the GNU System distribution." <[email protected]> writes:
> Hi all, > > On 2/13/26 16:36, Rutherther wrote: >> Git cherry pick... won't work, because then we cannot fast forward the >> master to current devel. We also cannot permit rebases on either of >> those branches, because that would mean users cannot pull from them. And >> also, as we've seen with next-mater, Codeberg doesn't handle rebases >> well at all when people open pull requests against the rebased branch, >> showing many more commits than are part of the PR. (as it doesn't >> understand them as patches, but as full branches and it diffs between >> the branches) >> >> So if we want to keep pushing some commits to master independently for >> security fixes, we would likely have to go for merges. The automated CI >> won't be able to do merges, because it cannot sign, so merges from devel >> to master don't seem feasible. So the only option I see us left with >> (maybe I am missing something) is merging master to devel manually when >> such situation arises. >> >> I think then it should be possible to fast forward "merge" master to >> devel, so the CI should be fine. > > A small note: > > Fast-forward merges from master to devel would only be possible when > there are no commits on devel yet. That is, when devel is pointing to a > commit in the history of master. Which I think is different from what > you propose. I meant to say devel to master, those done by CI. From master to devel these would have to be no ff merges as stated in the paragraph above. Rutherther > > So cherry-picks should be possible; at least by that argument. > > Another possibility is to artificially branch the security hot fix > branch early in the history (before a common ancestor of master and > devel), and then just merge it normally into both master and devel (and > any hypothetical release branch and whatever). > > Personally, I'm fine with graph of tangled branches; that is, merging > master into develop regularly. It's not so bad. > > A caveat for merging master into develop is that it only works well when > there are no version numbers hardcoded in master. So we'd need to have > release branches, or get the version from the git tag/branch. We already have release branches. > > Hugo > > P.S. about the CI merging devel into master: I strongly believe that > no-one should be able to merge into master locally and then push. > Because people that can do that will be a target for hackers. > > IMO, merges to master should *only* be done through codeberg. But I > don't have experience with how to do that with signing commits. We cannot do that with signing commits. Even when Forgejo supports it, the signing keys should be given only to humans as far as I understand the current policies. I don't really understand the argument, though. If one's computer becomes compromised, why wouldn't the malware be able to send a request to codeberg...
