On 2/13/26 17:57, Hugo Buddelmeijer wrote:
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 think I might have misunderstood in which direction you want to
fast-forward merge. I read "a to b" as "merging commits from a into b",
but you might have meant "merging such that a becomes equal to b". I'm
not sure. I'll shut up now to not cause any more confusion.
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.
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.
