From: zimoun <zimon.toutoune@gmail.com>
To: John Soo <jsoo1@asu.edu>
Cc: 41604@debbugs.gnu.org
Subject: bug#41604: guix pull impossible after rebasing a local repository
Date: Sat, 30 May 2020 12:45:07 +0200 [thread overview]
Message-ID: <CAJ3okZ3jSYqUJw0tETFtnpb8wC6oopPnrPBYKLCbkftn=WKiMQ@mail.gmail.com> (raw)
In-Reply-To: <87ftbinoo7.fsf@asu.edu>
Hi John,
On Sat, 30 May 2020 at 04:26, John Soo <jsoo1@asu.edu> wrote:
> Yeah guix pull --commit=1444040933 --allow-downgrades failed.
Hum? with this message:
--8<---------------cut here---------------start------------->8---
guix pull: error: Git error: object not found - no match for id
(57518fc7bf1efc899c0dabaa76685a319661f8e4)
--8<---------------cut here---------------end--------------->8---
?
> > Hehe! Dangerous zone. :-)
>
> I think I found that out, haha!
To be honest, I have tried to use the checkout
~/.cache/guix/checkout/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq
as local clone in order to rebase, worktree and apply patches. Bad,
really bad idea! The discipline to avoid breakage is too high. ;-)
> I guess that makes me wonder what the desired specification is.
> There is a lot of problem space to explore. As a user I would want to
> be able to take my local patches as "the real truth".
>
> Because guix has a linear git history, that means the user needs to
> always rebase. Often I have patches open for months that I am currently
> testing and working on. It would be convenient for me to be able to guix
> pull into my default user profile.
>
> On the other hand, as you point out, using a hash that disappears from
> the git history is dangerous. The git history no longer tracks the guix
> pull history and then there may exist pulls in history that may never be
> recoverable.
>
> There seems to be some existing support for the rebasing into the
> default profile since branches are allowed as references in the channels
> configuration. Has the rebase use case been discussed before? Oh, also,
> history items can be deleted in other places with --delete-generations
> and friends. I am not sure what to classify this problem, bug or
> something else.
I am not sure to see what is the desired specification. Well, I do
not know if my workflow is the good one but let me describe how it is
organised.
The local (master) checkout is at ~/src/guix/guix/ and then I only
checkout the branches using 'worktree' (thanks to Ricardo to show me
the tips during a "Skill Share" session on Dec. 2018 :-)). Well,
Magit helps a lot here.
Basically all my branches live under ~/src/guix/wk/. And when I test
patches, I always create a new branch. Well, I do not often rebase
enough so I never remember the 'onto' direction so I always read the
doc for that. :-)
(The price to pay with worktree is that I "compile" all Guix really
often because it does not reuse .go files; even if I tried to
synchronize the .go files to avoid such annoyance but I have failed.)
Just 'guix' refers to the one living at ~/.config/guix/current because
I always want that "guix install foo" refers to upstream. Well, I
never pull the latest commit from
https://git.savannah.gnu.org/git/guix.git because the substitutes are
almost never available so I pull 2 weeks behind. Basically, I do:
"git -C ~/.cache/guix/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq
pull" then
guix pull --commit=$(git -C ~/.cache/guix/<long-hash> \
--before=$(date --date='2 weeks
ago' +%Y-%m-%d) \
--format="%h" | head -n1)
And when I want to install something from one of the branches, it depends:
a- inside "guix environment guix" and ~/src/guix/wk/<name>
./pre-inst-env guix install foo -p /tmp/profile
and then I use this /tmp/profile as any other. Or I go with "guix
environment". Well, if it is something I want to hold, then I write
down the manifest and channel files.
b- inside "guix environment guix" and ~/src/guix/wk/<name>
./pre-inst-env guix pull --branch=<name> --url=$PWD -p ~/tmp/<name>
/tmp/<name>/bin/guix blabla
and I almost never track "permanently" such other guix.
For custom packages, I am more often using '--load-path' than 'channel'.
Last, I use more and more "guix time-machine". Well actually more
than b-, which I only use to test patches about "guix pull". Roughly
speaking,
- "guix environment" creates temporary profile
- "guix time-machine" create temporary pull
And with this new "authentication" of "guix pull", I think now, it
would be better to do:
guix time-machine --branch=<name> --url=~/src/wk/<name> -- blabla
Well, I do not know if all this is the correct way. But it is more or
less what I am doing to avoid annoyance.
All the best,
simon
next prev parent reply other threads:[~2020-05-30 10:46 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-29 16:38 bug#41604: guix pull impossible after rebasing a local repository John Soo
[not found] ` <handler.41604.B.159077032116756.ack@debbugs.gnu.org>
2020-05-29 16:41 ` bug#41604: Acknowledgement (guix pull impossible after rebasing a local repository) John Soo
2020-05-29 16:52 ` bug#41604: guix pull impossible after rebasing a local repository zimoun
2020-05-29 17:10 ` John Soo
2020-05-29 17:44 ` zimoun
2020-05-29 18:22 ` John Soo
2020-05-29 18:39 ` zimoun
2020-05-30 2:26 ` John Soo
2020-05-30 10:45 ` zimoun [this message]
2020-05-30 16:18 ` Arne Babenhauserheide
2020-05-31 5:04 ` John Soo
2020-06-01 16:48 ` zimoun
2020-06-01 17:28 ` John Soo
2020-06-01 16:35 ` zimoun
2020-06-03 9:28 ` Ludovic Courtès
2020-06-03 13:44 ` John Soo
2020-06-03 15:13 ` Ludovic Courtès
2020-06-04 14:11 ` John Soo
2020-06-05 1:44 ` zimoun
2020-06-05 16:13 ` Ludovic Courtès
2020-06-05 1:23 ` zimoun
2020-06-05 16:17 ` Ludovic Courtès
2020-06-05 17:51 ` zimoun
2020-06-07 21:16 ` Ludovic Courtès
2020-06-07 22:25 ` zimoun
2020-06-07 23:52 ` John Soo
2020-06-10 14:51 ` Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAJ3okZ3jSYqUJw0tETFtnpb8wC6oopPnrPBYKLCbkftn=WKiMQ@mail.gmail.com' \
--to=zimon.toutoune@gmail.com \
--cc=41604@debbugs.gnu.org \
--cc=jsoo1@asu.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
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).