I am preparing to install Guix System for the first time on my new computer by watching System Crafters’ youtube videos and reading Guix reference and other web pages. I’ve got a question about managing configuration files for Guix by git: How do you synchronize the Guix generations and git commit ID? In other words, if I know a Guix generation and want to know the corresponding git commit ID (or vice versa), how can I do so?
As far as I understand, Guix internally stores sufficient information to reproduce each generation of the system state and user profiles, and Guix can output configuration files and manifest files to do so. At the same time, it seems to be recommended to version-control the configuration files and manifest files for a user to edit and pass to guix system, guix home, guix package, etc. by git. However, I don’t find information about linking the two lines of history in Guix and git. Do people just don’t encounter an occasion to look up the git log for a particular Guix generation or track down a Guix generation while analyzing the git log about some issues?
I’m not sure if i understand what you mean, but you can get the commit hashes from your current system by running guix describe -f channels. That will output the information directly in scheme, which means you can literally just copy and paste that output into a file, put it into version control, and on a different machine run guix time-machine and point it to that file. One thing i recently found out about though since i’m quite new to guix myself is that if you usually do your guix pulling on one machine and then update your other machines with time machine, you should probably still run guix pull on those other machines first as well. I encountered an issue on my laptop, which i never ran guix pull on and instead just used time-machine, where it started complaining about my nonguix channel being unauthorized or something. running guix pull on my laptop solved the issue.
I want to clarify my question by taking this System Crafters’ webpage as an example.
Here the author recommends to put operating-system configuration file and home-environment configuration file as well as other files under ~/dotfiles directory and version-control them by git. These are files we, the users of our own machines, edit time to time to modify our system, install packages, etc.
To my understanding, guix describe -f channels outputs the git commit ID of the channels, such as guix and nonguix, managed by someone else than us, the users of the computers at hand. Which channels to be used are defined in ~/.config/guix/channels.scm by default.
Continuing with the example of System Crafters webpage above, and as far as I understand,
guix system reconfigure takes ~/dotfiles/config/systems/gemini.scmand other scm files as well as ~/.config/guix/channels.scm as input and outputs a new state of the operating system. Guix assigns a new generation number to this state. It records ~/dotfiles/config/systems/gemini.scmand other scm files as well as the git commit ID of the channels from which guix systemand other guix tools as well as packages were generated, so that the exact same system state can be re-created in the future or on another machine. However, Guix doesn’t record the git commit ID of ~/dotfiles/config/systems/gemini.scm and other config files under ~/dotfiles/ because it doesn’t know whether `~/dotfiles/` are under git version control.
Now, suppose that I find an issue in my ~/dotfiles/config/systems/gemini.scm at some point in time, and that I review the history of how I have edited this file with git. When I find a particular git commit ID at which a problematic code fragment was inserted, I may want to recreate the state of the system corresponding to this version of ~/dotfiles/config/systems/gemini.scm. However, the git commit ID of this version of this file is not recorded by Guix anywhere, and it’s not linked to the system generation number. I may need to track down the system generation number manually by taking date and other information as hints and by comparing the outputs of guix describe and git checkout. I wonder how people deal with this situation. I guess that they may have implemented a mechanism to link the git commit ID of system configuration files and system generation number automatically.
I just run `guix system reconfigure` from a helper script in my guix config repository. The script checks that the repo is clean and also records the `guix describe -f channels` output and makes a new commit if the reconfigure succeeds. This way I can correlate the git log to the system generations and I can reproduce every generation by utilizing the configs in the commit together with the recorded commits per channels.
thank you for your comment. Your reconfiguration process sounds nice.
I felt a bit of resistance to storing the output of a script in a git repository because I have had an idea that outputs from a program or script shouldn’t be stored in a git repository and that I should store only files that have been manually created. However, when I examine the reasoning behind this idea about what to store and what not, I realize that a precise criterion should be whether the file can be recreated or not. As an event log of system reconfiguration, the output from the script is not reproducible, and I convinced myself that it may qualify to be stored in the git repository.
I don’t. So far, when I got in trouble, I just kept rolling back Guix generations until stuff worked again, while listing all the user packages I installed. Then rolled back my git config and reinstalled my user packages.
In fact, I don’t think I even had a git config back then and rolled it back from vim (meaning local) history. I still haven’t even gotten to the point to even organize my guix configuration. Maybe I’ll try doing that today.
Though I’m just a plain user. I’m not sure what your use case is.
thank you for your reply. I imagine your style may be what most people adopt because I don’t see almost any information about linking config files’ git repo and Guix. And, probably it’s just fine for me, too, as a user not engaged in a critical work, to forget about linking them. If I ever need to roll back Guix, I can find a corresponding commit of git by manual inspection as you suggested. However, this manual labor could become too much mental work for me when I’m overwhelmed by other tasks. I have recently worked on synchronizing the file trees of a few machines, and I had to guess like a detective what I had done on each of the machines to make sense of the difference among them. This experience was not about Guix, and there was enough log for me to successfully complete the synchronization task. Nevertheless, I was rather exhausted and come to wish to incorporate as sophisticated logging mechanism as I can have to wherever appropriate.