guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Rebasing or merging? [was: Re: 01/03: gnu: wxwidgets: Add libxtst to


From: Maxim Cournoyer
Subject: Re: Rebasing or merging? [was: Re: 01/03: gnu: wxwidgets: Add libxtst to inputs.]
Date: Mon, 12 Jun 2023 09:47:32 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)

Hi Andreas,

Andreas Enge <andreas@enge.fr> writes:

> Hello,
>
> Am Sun, Jun 11, 2023 at 06:10:37PM -0700 schrieb Felix Lechner:
>> That was probably a misunderstanding. I meant to suggest with some
>> trepidation that 'master' is merged into the feature branch, and then
>> the feature branch is merged back into 'master'. I thought the two
>> merge commits would be signed by the person performing the merges
>> while the "origin seal" of the accepted change is also preserved.
>
> indeed, that is what we had been doing with the very long lived staging
> and core-updates branches in the past. Well, we used to repeatedly merge
> the master branch to core-updates, which if I remember well makes the
> master commits end up first in "git log". So the core-updates specific
> commits gradually disappear below thousands of master commits. So this is
> a problem.
>
> But Maxim is right about signatures, sorry for forgetting them time and
> again!
>
> One policy would be to *not* merge master back to the feature branch
> (or maybe just before merging the feature branch to master). This would
> work well for short-lived branches.

Yes, I think we should document as policy that there should be no merge
to the feature branches unless really necessary.  This will remove a lot
of noise from the commit history and keep things in the feature branch
focused.

-- 
Thanks,
Maxim



reply via email to

[Prev in Thread] Current Thread [Next in Thread]