Hi Ludo! I hope you are well. Ludovic Courtès writes: > What happens is that ‘guix pull’ ensures that it only ever makes > “fast-forward” updates by default, in Git parlance. The goal is to > detect obvious “downgrade attacks”: > > https://issues.guix.gnu.org/41425 Oh I see, I'm sorry I did not participate in that issue, now. That makes sense and I'm glad to know this is part of the design. > (This can be overridden this by passing ‘--allow-downgrades’.) Does '--allow-downgrades' support unrelated git histories? I tried that flag and it did not work. > The rebase workflow you describe unavoidably triggers the error because > every time you pull, you do a non-fast-forward pull (because the commit > you were previously using, as shown in ‘guix describe’, has been > rewritten and no longer exists in the new commit graph.) So at least, > it shows that the machinery works as advertised. :-) Totally. I think I understand the design goal now. > What I would recommend is for your channel to be a regular “fork”: you > create a branch containing your patches and regularly merge upstream > master back into your branch. That way, you don’t need to rewrite > history and ‘guix pull’ is happy. So far the need to avoid downgrade attacks makes sense. Here are the things I think should be considered: I have branches based on master in savannah that contain specific patch sets associated to patch requests upstream. I think I have 3 or 4 right now. My patches are also in the branch I have in channels.scm. I do that for a few reasons: 1. To test the patches 2. To workaround or use bugs/features/packages I want but are not upstream yet. That means I tend to want to use my patches whether or not they are upstream yet. In fact I stopped working on my channel because it was so easy to just make patches on upstream to contribute back. It can take many months for patches to be merged. That is expected since we are all volunteers. Rebasing the patches is the easiest way to keep them up to date so they can be applied cleanly. There are two design and community goals I love about Guix: hackability and inclusivity. I feel that disallowing linear history makes the easiest way to contribute to, hack on, and participate in Guix much harder without proper support. For instance: instead of making patches on top of upstream it is now easier just to work on my channel. Certainly some tradeoffs should be made for security and I think your recent commit authentication work does that elegantly. Perhaps we can easily have hackability and security with a flag like --allow-downgrades called --allow-unrelated that allows the rebase workflow. WDYT? > Alternately, if you like to have linear history (for example because you > intend to eventually submit your patches upstream), you could use > TopGit, which roughly allows you to version-control your rebases. Hmm. I am unaware of TopGit but I find rebasing to be the simplest and easiest way to do my work. I'll look into it but I would rather not have to use another tool for simplicity's sake. > From a pure Guix perspective, it’s “not-a-bug”. If one of the above > suggestions works for you, I think we can close this issue. I think I understand the reasoning now. I do hope a flag like --allow-unrelated might solve all the things. > HTH! Thanks as always. I really appreciate your communications. - John