Efraim Flashner <efr...@flashner.co.il> writes: > On Sun, Jun 09, 2024 at 10:46:10AM +0100, Christopher Baines wrote: >> guix-comm...@gnu.org writes: >> >> > efraim pushed a change to branch core-updates >> > in repository guix. >> > >> > from c8c6883398 gnu: dico: Add libxcrypt dependency. >> > new 9804f8c149 gnu: coeurl: Update to 0.3.1. >> > new 51c7b6d76f gnu: font-gnu-freefont: Build with newer fontforge. >> > new 0e06c9697a gnu: Remove fontforge-20190801. >> > >> > The 3 revisions listed above as "new" are entirely new to this >> > repository and will be described in separate emails. The revisions >> > listed as "add" were already present in the repository and have only >> > been added to this reference. >> >> These changes confused me as I was looking at the trying to work out why >> they needed to be pushed to core-updates. Eventually I figured out that >> Git is right, these commits are entirely new, but they duplicate >> existing commits already pushed to master (e.g. 0e06c9697a is a >> duplicate of 3d5f4b2d7dda). >> >> I know the new guidance says to "Avoid merging master in to the branch", >> but one of the reasons for that is to avoid situations just like this >> where merges are done incorrectly and commits are duplicated between >> branches. >> >> To fix this, I think we should rebase core-updates on master and drop >> these commits. > > I wasn't aware I was "doing it wrong" with this, I saw that coeurl 0.3.0 > failed on core-updates but a bump to 0.3.1 fixed the build, and it could > go to master also. Similar story with working to remove > fontforge-20190801 which no longer built on core-updates. I figured that > applying the patch to both branches would make it easier to merge master > into core-updates since there would be less drift between the two.
You're right regarding drift, but unfortunately I think this duplication of commits creates merge conflicts, or at least makes them much more likely. > What is the correct way to apply a patch to multiple branches? I'd frame the problem differently, we don't want multiple branches, we want everything on master. Unfortunately for some changes that is hard to test and creates too much churn, so for those changes they go to a branch where they can be built and tested prior to pushing/merging them to master. To avoid changes happening on a topic branch and master, I think it's important that any change that can be made on master, is made on master. That should avoid the problem where someone else comes along and doesn't realise a change has been made on core-updates, and duplicates that on master. In this instance, you pushed the changes to master, which is great. I realise it does require more up front effort, but if you see a failing build on a topic branch that's fixed by some change on master, the topic branch should be rebased to include those changes. Providing it's done correctly, merging should be fine as well, but the docs now say to avoid that and prefer rebasing (mostly because of how merging has introduced duplicate commits in to core-updates) This rebasing or merging will minimise the drift between the two branches as well, while avoiding Git conflicts and commit duplication. So I don't think we want to be applying patches to multiple branches. If it can be applied to master, it should be applied there, then all the branches should be rebased to include it. Does that make sense? This isn't really a "doing it wrong" thing, more that we need to try and optimise the process for managing branches. I haven't got a concise definition of what we're trying to optimise for, but in this instance we want to avoid Git issues like merge conflicts and avoid duplication and complexity by making changes that can be made on master, just on master.
signature.asc
Description: PGP signature
