bug#41604: guix pull impossible after rebasing a local repository

[John Soo]

Hi Ludo!

I hope you are well.

Ludovic Courtès <ludo@gnu.org> 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