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

[John Soo <jsoo1@asu.edu>]

Hello again,

zimoun <zimon.toutoune@gmail.com> writes:

> On Sun, 31 May 2020 at 07:04, John Soo <jsoo1@asu.edu> wrote:
>
>> My problem largely comes from the fact that I specified a branch in
>> channels.scm for over a year with the same workflow. If a branch can
>> be specified for a channel repo then the system probably should
>> handle the current pull commit not being available in the history.
>
> What do you mean?

Well if a channel specification has a branch then the channel
specification explicitly allows the commit history to not always have
the commit from "guix describe".  For example, say the channels.scm file
has the following:

(list
 (channel
  (name 'example-channel)
  (url "https://git.example.com/repo")
  (branch "example-branch"))
 ...)

the maintainer of example-channel may rebase example-branch on some
other branch.  Then guix-pull will indeed be impossible for anyone who
has example-channel specified with the branch field in channels.scm.

So what I am saying is that if unrelated histories are to be disallowed
during "guix pull" then branches should not be allowed in channel
specifications.

>> The commit history authentication is nice but seems to have
>> regressed this particular use case.
>
> I am not sure that the new history authentication is the issue here.
> IMHO, it is just the feature that shows up the flaw with your
> workflow. ;-)

You are right, I should not assume what introduced my problem. What I do
know is that this workflow worked for the last year or more until last
week. I should do a bisect to find the exact commit.

>>From my understanding, Guix is built around content-addressed
> principles (channel, store, etc.) so try to change on the fly the
> address of such content would lead to break one way or another, IMHO.
>
>
> Well, is the issue fixed for you now?

The issue is not fixed and I think I found another problem with the
workaround.  To reiterate, my workaround is to "guix pull --roll-back"
until a generation that has a the commit that is in my history then
"guix pull" again to get my new work. The problem is the next "guix
pull" shows all news from the old commit until the newest commit. In
other words I get the news I saw from the previous time I pulled plus
any new work. In this way the news continues to accumulate making the
news less and less useful and more and more noisy.

Btw, I am totally with you on pijul/darcs or some patch theory version
control. Pijul does indeed look pretty promising. I packaged it in my
channel if you want to try it :).

Kindly,

John