Hi, On Thu, 16 Jan 2025 at 15:34, Liliana Marie Prikler <liliana.prik...@gmail.com> 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
