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

[Ludovic Courtès]

Hello,

John Soo <jsoo1@asu.edu> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:

[...]

>> (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.

It supports unrelated Git histories.  It could really be called
‘--allow-anything’ but I thought it’d be less descriptive.  :-)

If you hit a problem with that, please report it (perhaps I just
overlooked it in the other issue.)

> 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.

Yes.

> 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.

Interesting, I hadn’t thought about how this mechanism would give an
incentive to have a channel vs. contributing directly upstream.

Normally, ‘--allow-downgrades’ does exactly what you need, at least
that’s the intent.  I’d argue that it’s also reasonable to use it in
this case because obviously you know what you’re doing, and you’re
pulling from a local Git repository, so that’s fine.

>> 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.

Yeah, that makes sense to me.

Thanks,
Ludo’.