Frequently-rebased channels

Frequently-rebased channels

[divoplade]

Dear guix,

I have a couple of channels that get rebased constantly. Is there a way
to tell guix that a channel allows downgrades, in a way that can also
be used by the unattended upgrade service? Also, if a package has a
git-fetch origin, the daemon will check that future versions are direct
descendants of its commit. Is there a way to tell the daemon not to do
that?

To be clear, I can run:

guix pull --allow-downgrades

and:

guix system reconfigure --allow-downgrades

but I would like for specific channels for the former and specific
packages for the latter to mean --allow-downgrades automatically, even
for the unattended upgrade service. 

If that’s not possible, is it possible to configure the daemon and the
unattended upgrade service to always use --allow-downgrades?

Re: Frequently-rebased channels

[Ricardo Wurmus]

divoplade <d@divoplade.fr> writes:

> I have a couple of channels that get rebased constantly.

This seems like a broken workflow.  Why would they be rebased
constantly, which results in rewritten history?

-- 
Ricardo

Re: Frequently-rebased channels

[divoplade]

Hello,

Le vendredi 09 avril 2021 à 14:21 +0200, Ricardo Wurmus a écrit :
> > I have a couple of channels that get rebased constantly.
> 
> This seems like a broken workflow.  Why would they be rebased
> constantly, which results in rewritten history?

Sorry, I don’t know how to respond to that. Of course, rebasing is
essential with git, precisely because it results in rewritten commit
history. The opposite (never rebasing) would be a broken workflow.

Re: Frequently-rebased channels

[Ricardo Wurmus]

divoplade <d@divoplade.fr> writes:

> Hello,
>
> Le vendredi 09 avril 2021 à 14:21 +0200, Ricardo Wurmus a écrit :
>> > I have a couple of channels that get rebased constantly.
>> 
>> This seems like a broken workflow.  Why would they be rebased
>> constantly, which results in rewritten history?
>
> Sorry, I don’t know how to respond to that. Of course, rebasing is
> essential with git, precisely because it results in rewritten commit
> history. The opposite (never rebasing) would be a broken workflow.

I’m not saying that rebasing is bad.  I’m saying that for public
channels it’s the wrong workflow as it results in rewritten history.

-- 
Ricardo

Re: Frequently-rebased channels

[divoplade]

Le vendredi 09 avril 2021 à 15:52 +0200, Ricardo Wurmus a écrit :
> I’m saying that for public
> channels it’s the wrong workflow as it results in rewritten history.

My channels aren’t public (they are git repos on the file system), but
I fail to understand how it makes a difference. Maybe the
misunderstanding is in the term "rewritten history", which can refer to
history (past releases of a package) or the git commit hierarchy? It’s
important not to confuse them.

Re: Frequently-rebased channels

[Ricardo Wurmus]

divoplade <d@divoplade.fr> writes:

> Le vendredi 09 avril 2021 à 15:52 +0200, Ricardo Wurmus a écrit :
>> I’m saying that for public
>> channels it’s the wrong workflow as it results in rewritten history.
>
> My channels aren’t public (they are git repos on the file system), but
> I fail to understand how it makes a difference. Maybe the
> misunderstanding is in the term "rewritten history", which can refer to
> history (past releases of a package) or the git commit hierarchy? It’s
> important not to confuse them.

I’m talking about git commits.

“guix pull” fetches from channels, which are git repositories.  When git
history is rewritten (e.g. with a rebase) it has no way of forwarding to
the new state.

Have you considered using a merge-based workflow for these channels?
Or, since these channels aren’t public, perhaps using GUIX_PACKAGE_PATH
would be more convenient?

-- 
Ricardo