unofficial mirror of help-guix@gnu.org 
 help / color / mirror / Atom feed
* Frequently-rebased channels
@ 2021-04-09 12:06 divoplade
  2021-04-09 12:21 ` Ricardo Wurmus
  0 siblings, 1 reply; 6+ messages in thread
From: divoplade @ 2021-04-09 12:06 UTC (permalink / raw)
  To: help-guix

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?



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Frequently-rebased channels
  2021-04-09 12:06 Frequently-rebased channels divoplade
@ 2021-04-09 12:21 ` Ricardo Wurmus
  2021-04-09 12:57   ` divoplade
  0 siblings, 1 reply; 6+ messages in thread
From: Ricardo Wurmus @ 2021-04-09 12:21 UTC (permalink / raw)
  To: divoplade; +Cc: help-guix


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


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Frequently-rebased channels
  2021-04-09 12:21 ` Ricardo Wurmus
@ 2021-04-09 12:57   ` divoplade
  2021-04-09 13:52     ` Ricardo Wurmus
  0 siblings, 1 reply; 6+ messages in thread
From: divoplade @ 2021-04-09 12:57 UTC (permalink / raw)
  To: Ricardo Wurmus; +Cc: help-guix

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.



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Frequently-rebased channels
  2021-04-09 12:57   ` divoplade
@ 2021-04-09 13:52     ` Ricardo Wurmus
  2021-04-09 15:40       ` divoplade
  0 siblings, 1 reply; 6+ messages in thread
From: Ricardo Wurmus @ 2021-04-09 13:52 UTC (permalink / raw)
  To: divoplade; +Cc: help-guix


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


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Frequently-rebased channels
  2021-04-09 13:52     ` Ricardo Wurmus
@ 2021-04-09 15:40       ` divoplade
  2021-04-09 17:52         ` Ricardo Wurmus
  0 siblings, 1 reply; 6+ messages in thread
From: divoplade @ 2021-04-09 15:40 UTC (permalink / raw)
  To: Ricardo Wurmus; +Cc: help-guix

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.



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Frequently-rebased channels
  2021-04-09 15:40       ` divoplade
@ 2021-04-09 17:52         ` Ricardo Wurmus
  0 siblings, 0 replies; 6+ messages in thread
From: Ricardo Wurmus @ 2021-04-09 17:52 UTC (permalink / raw)
  To: divoplade; +Cc: help-guix


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


^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2021-04-09 17:53 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-04-09 12:06 Frequently-rebased channels divoplade
2021-04-09 12:21 ` Ricardo Wurmus
2021-04-09 12:57   ` divoplade
2021-04-09 13:52     ` Ricardo Wurmus
2021-04-09 15:40       ` divoplade
2021-04-09 17:52         ` Ricardo Wurmus

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).