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

From: Efraim Flashner <[email-masked]>
Date: Sun, 9 Jun 2024 12:54:27 +0300

On Sun, Jun 09, 2024 at 10:46:10AM +0100, Christopher Baines wrote:
> [email-masked] 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.

What is the correct way to apply a patch to multiple branches?

-- 
Efraim Flashner   <[email-masked]>   רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted