[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Non-committers can't keep authenticated forks updated
From: |
Nicolas Graves |
Subject: |
Re: Non-committers can't keep authenticated forks updated |
Date: |
Fri, 17 Jan 2025 22:44:42 +0100 |
On 2025-01-16 15:34, Liliana Marie Prikler wrote:
>> The complexity is due to the requirements of not bumping the channel
>> introduction (to avoid the increased attack surface from having to
>> keep obtaining the updated one, as I discussed earlier), keeping fork
>> history intact (to avoid force pulls), keeping upstream history
>> intact, and being able to authenticate both upstream and fork
>> commits. If you can think of a simpler method that meets these
>> requirements, I'd love to hear it.
> Guix committers are more than happy to use work trees and rebases,
> which simplify this a lot – again, it's as simple as pull,
> authenticate, rebase.
>
> W.r.t. keeping history intact, we had the following exchange on IRC
> yesterday.
>
> <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.
>
A lightly-related comment :
I recently started a guix extension to help manage complexities of
maintaining guix soft-forks. I haven't advertised it yet, and I'm fine
authenticating locally for now. I mainly focus on reproducibility of
patches sent (recording where patches are sent to be able to generate a
list of <origin> patches from a repo) and pulling from patched channels.
There still some work ahead before I can even advertise it properly, but
feel free to take a look! There's no doc yet.
https://git.sr.ht/~ngraves/guix-stack
--
Best regards,
Nicolas Graves
- Re: Non-committers can't keep authenticated forks updated, (continued)
- Re: Non-committers can't keep authenticated forks updated, Tomas Volf, 2025/01/16
- Re: Non-committers can't keep authenticated forks updated, 45mg, 2025/01/16
- Re: Non-committers can't keep authenticated forks updated, Tomas Volf, 2025/01/16
- Re: Non-committers can't keep authenticated forks updated, Liliana Marie Prikler, 2025/01/16
- Re: Non-committers can't keep authenticated forks updated, Tomas Volf, 2025/01/17
- Re: Non-committers can't keep authenticated forks updated, 45mg, 2025/01/16
- Re: Non-committers can't keep authenticated forks updated, Liliana Marie Prikler, 2025/01/16
- Re: Non-committers can't keep authenticated forks updated, 45mg, 2025/01/16
- Re: Non-committers can't keep authenticated forks updated, Saturanya Rahjane de Lasca, 2025/01/18
- Re: Non-committers can't keep authenticated forks updated, Tomas Volf, 2025/01/17
- Re: Non-committers can't keep authenticated forks updated,
Nicolas Graves <=
- Re: Non-committers can't keep authenticated forks updated, 45mg, 2025/01/18
Re: Non-committers can't keep authenticated forks updated, Attila Lendvai, 2025/01/15