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