Subject: Re: bug#75552: Non-committers can't keep authenticated forks updated

From: Simon Tournier <[email-masked]>
Date: Mon, 03 Feb 2025 16:40:55 +0100

Hi,

On Thu, 16 Jan 2025 at 15:34, Liliana Marie Prikler <[email-masked]> wrote:

> <Rutherther>	lfam: that's interesting that there is really a merge
> commit, for example if I remember right, the core updates merge few
> months ago happened by directly appending the commits instead of a
> merge commit
> <lfam>	Yes, there are two ways to do it (rebase and merge) and it's a
> matter of taste
> <lfam>	Of course there is a correct choice, as with all questions of
> taste ;)
> <Rutherther>	I personally prefer a merge commit, since it has two
> parents, you can track where the previous master pointed to
> <lfam>	And I prefer a rebase. But ultimately it's up to whoever is in
> front of the keyboard
> <lilyp>	FWIW, a rebase is cleaner, but requires that only one person
> signs off commits on any given branch (or else you're signing commits
> that someone else signed before and have to update the trailer… not
> ideal)
> <lfam>	It doesn't matter who signs the commits as long as they are
> authorized. That's the security model we have
>
> So yeah, even for (branch-)local work at least some committers prefer
> rebasing.

To my knowledge, the (implicit) policy used by the Guix project is to
rebase or fast-forward marge and exceptionally apply merge.  This choice
easily simplifies when one digs into the history: it simplifies ’git
bisect’ and also the “guix time-machine” substitutes coverage.

Maybe, I’ve missed something but it’s not only some committer’s
preference. :-)

Cheers,
simon