Re: branch core-updates updated (c8c6883398 -> 0e06c9697a)

[Christopher Baines]

Efraim Flashner <efraim@flashner.co.il> writes:

> On Sun, Jun 09, 2024 at 10:46:10AM +0100, Christopher Baines wrote:
>> guix-commits@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