Assumptions

• The user has git tracked flake.nix providing one or more nixosConfigurations on a dotfiles repo.
• The user doesn't mind having automatically generated (and very basic) commit messages. Uses other tools for anything else.
• The user benefits from having some quick shortcuts only to perform the most common/repetitive tasks on a dotfiles repo. Uses other tools for anything else.

Read Rationale for further explanations.

Configuration

Use the following environment variables to override jkl's default behavior:

1. JKL_FLAKE_DIR (defaults to $HOME/.dotfiles/nixos).
   • You can use the default and make a symbolic link pointing from $HOME/.dotfiles/nixos to another git tracked directory containing your flake.nix file.
   • Depending on how you define this variable, you may have to use $HOME/a/b/c instead of ~/a/b/c
2. JKL_COMPUTER_NAME (defaults to $HOSTNAME).

   • There is no need to set a custom JKL_COMPUTER_NAME if you set your nixosConfiguration.<computer_name>'s to be equal to the networking.hostName used for each of the corresponding nixosConfigurations. See how for the example below, ./computers/computer_a.nix and ./computers/computer_b.nix declare networking.hostName="computer_a_name"; and networking.hostName="computer_b_name";, respectively.

     {
       outputs = { self, nixpkgs, ... }@inputs:
         let
           commonModules = [ ./configuration.nix ];
         in
           {
             nixosConfigurations.computer_a_name = nixpkgs.lib.nixosSystem {
               system = "x86_64-linux";
               modules = commonModules ++ [ ./computers/computer_a.nix ];
             };
             nixosConfigurations.computer_b_name = nixpkgs.lib.nixosSystem {
               system = "x86_64-linux";
               modules = commonModules ++ [ ./computers/computer_b.nix ];
             };
           };
     }

Usage

Configure variables if needed (see configuration), then run:

$ jkl [extra args passed to nixos-rebuild]

jkl will show:

1. git status followed by:
2. A menu with the following options:

=================================== Select operations to perform on <HOSTNAME>

a - stage (all)
s - scan
d - diff unstaged
D - diff staged
e - diff origin
f - fetch
g - merge origin
h - commit & push

j - rebuild
k - commit, push & rebuild
l - commit, push, update flake.lock & rebuild
L - update invididual <input>
x - collect garbage

After hitting any of a,s,d,D,e,f,g,h,j,k,l,L, x, the menu options will disappear, leaving the output of git status, one colored line message showing the option you choosed:

h ================================> Commit & push

And the outpout of the choosen actions being performed, after this line.

Recursive actions

The a - stage and d - diff unstaged, D - diff staged, e - diff origin, f - fetch, g - merge and L - update individual <input> options are recursive, after the corresponding actions are perfomed the menu automatically shows again, with the git status updated.

f - fetch shows the output of git diff origin on less after running git fetch, unless there is nothing to fetch, in that case it shows the main menu directly.

Scrollback buffer

jkl Doesn't clears the scrollback buffer of your terminal, meaning, at any time after using jkl, (at least, before you kill/clear your terminal) you can inspect both the git status, the choosen action/s from the menu, and the output of the choosen actions. Just like with regular git/nix used from a terminal.

Screenshots

$ jkl

Before choosing action/s:

After choosing action/s with j:

Scrollback buffer example:

Rationale

The program's name (jkl) is not a joke. These three consecutive home row keys used to write the program name on a terminal, the <Control-m> you can use to submit the command on most terminals, and any of the (most likely to be used repeateadly) h, j,k,l actions, can be pressed in sequence with a gesture of the hand, that doesn't even qualifies as writing. It takes less than a second to use this command, if you memorize at least the action/s that you use the most.

This allows to efficiently try, commit & push any (valid) minuscule tweak in you configuration, almost for free. Which is specially useful in a multi computer setup sharing the same configuration. This is done while keeping the (clean & readable) history on a terminal, without the user having to cd into any particular folder, provide a computer name or commit message, and with the help of some also efficient to use wrappers around git fetch, merge, stage, diff and nix input/s update.

Dependencies

• bash
• tput (provided by ncurses)
• less
• nix
• git
• git-secrets

All dependencies are provided if you use the flake.

To use git-secrets (with s - scan) you have to provide a secrets provider, using for example:

git secrets --add-provider -- gpg -qd /path/to/my_secrets.gpg

Where my_secrets.gpg is just a text file encrypted with gpg -c /path/to/my_secrets (dont forget to remove the -unencrypted- original file)

This is the same as using cat without encryption:

git secrets --add-provider -- cat /path/to/my_secrets