Do, or do not. There is no try, Yoda.

The problem is not the problem. The problem is your attitude about the problem, Captain Jack Sparrow

Introduction to NixOS

NixOS is a unique, innovative, and powerful Linux distribution that leverages the Nix package manager. Unlike traditional Linux distributions that update packages and system configurations in-place, NixOS uses a purely functional and declarative approach to define the system state, reducing the risk of system breakage.

NixOS is a Linux distribution that uses the Nix package manager to handle packages and system configuration in a purely functional manner. This approach ensures that builds are reproducible and that the system state can be reliably replicated or rolled back.

Immutable Design: It uses a configuration file (usually /etc/nixos/configuration.nix) to define the entire system state, including installed packages, services, and system settings. This makes the system “immutable” in the sense that you don’t manually modify system files. Instead, you declare what you want, and NixOS builds the system from that declaration.
Atomic Updates: When you run nixos-rebuild switch, the system builds a new generation of the environment. If the build is successful, you can switch to this new environment atomically. This means that either the entire update is applied, or nothing changes at all, preventing partial updates that could leave the system in an inconsistent state: sudo nixos-rebuild switch, build and switch to the new generation. If anything goes wrong, you can easily roll back to a previous generation: sudo nix-env ‐‐rollback This rollback is seamless because each generation is stored separately.
sudo nix-env ‐‐rollback is a command used to revert your system to the previous configuration. It’s a powerful tool for undoing unintended changes or recovering from failed package installations. Before rolling back, consider if there’s a more targeted solution, like uninstalling specific packages or reverting configuration files.
Purely Functional System Configuration: NixOS uses a functional paradigm for configuration. This means that changes are expressed as pure functions from a configuration to a system state, ensuring reproducible builds and easy rollback.

Hyperland

Hyprland is a modern, dynamic tiling Wayland compositor that offers a highly customizable and modern desktop experience. In NixOS, you can install and configure Hyprland declaratively, allowing you to manage your system configuration (such as display managers, NVIDIA drivers, user permissions, and sound servers) in a reproducible manner from a single or a few .nix files.

git

Git is a distributed version control system designed to track changes in source code during software development. Git is also a fantastic tool for managing and maintaining your dotfiles.

Installing Git in NixOS’s Configuration File. Install the git package in NixOS’s main configuration file, /etc/nixos/configuration.nix:
```
{ config, pkgs, ... }:

{
  environment.systemPackages = with pkgs; [
    git
    # ... possibly other packages ...
];
}
```
Then rebuild your system: sudo nixos-rebuild switch

Configuring Git with Home Manager. If you use Home Manager, you can store personal Git configurations in your user profile instead of configuring it system-wide, e.g., nvim ~/dotfiles/home-manager.nix:

  programs.git = {
    enable = true; # Activates Git in Home Manager.
    userName = "YOUR-NAME";
    # We define the default Git identity for commits with userName and userEmail.
    userEmail = "YOUR-EMAIL";
      extraConfig = {
		    init = {
          # Sets the default initial branch name to “main” instead of “master.”
      		  defaultBranch = "main";
      		  safe.directory = "/etc/nixos";
		    };
    };
   };

By adding /etc/nixos to safe.directory, you are telling Git it’s safe to run Git commands in /etc/nixos, which is useful if you keep your NixOS configurations under version control.

After adding these settings, rebuild your Home Manager configuration, e.g.: home-manager switchor sudo nixos-rebuild switch.

Initializing Repositories in /etc/nixos and /home/dotfiles. We assume you have two separate directories you want under Git version control:

/etc/nixos: for your system configuration (e.g. configuration.nix). It often requires root permission.

/home/dotfiles: for your user’s dotfiles.

cd /etc/nixos
sudo git init # Initializes a new Git repository in /etc/nixos.
sudo chown YOUR-NAME:users .git.
# Makes YOUR-NAME the owner of the newly created .git directory, ...
# allowing you to run Git commands without root

cd /home/dotfiles
git init # Initializes a new Git repository in /home/dotfiles,...
# but no special ownership changes is needed because you already own your home directory.

Once both repositories are initialized, inside one of them, you may want to stage all files for an initial commit: git add * This command stages (places in a temporary location) all files in the current directory, making them ready for commit. You can also selectively stage specific files or directories, e.g. git add home-manager.nix, git hyprland.nix, etc.
Committing Changes: git commit -m "My first NixOS configuration, 12/24. -m provides an inline commit explanation message. A commit represents a snapshot of your project at a specific point in time. Each commit saves the state of the entire repository, allowing you to keep track of changes and revert to previous states if needed. This records all staged changes with the message My first NixOS configuration, 12/24.
Adding a Remote Repository. Let’s back up or sync our local repository (with our configuration.nix and dotfiles) with a remote one, say, GitHub: git remote add origin https://github.com/YOUR-USER/justtothepoint.git where origin is the conventional name for your main remote. Obviously, you need to replace the URL with your actual remote repository address.
Pushing Changes to GitHub: git push -u origin main. If your default upstream branch (the branch that your local branch is set to push to and pull from by default: -u origin main) is main, this command pushes your local commits to the remote main branch. After this, you can just run git push for subsequent pushes.

This won't work with just your password. You must use a personal access token. remote: Support for password authentication was removed on August 13, 2021.

Creating a Personal Access Token (PAT) on GitHub

From your GitHub account, go to Settings → Developer Settings → Personal Access Token → Tokens (classic).
Generate New Token (you are likely to be prompted for your password).
Fill up the form with the scopes you need.
Click Generate token, and copy the generated Token in a very safe place (e.g., KeePassXC, pass, etc.).
The new order to set the remote using your token is: git remote set-url origin https:// + YOUR_TOKEN@github.com + /YOUR-USERNAME/YOUR-REPOSITORY.git.
If you want to clone a private repository with your token: git clone https: + //YOUR_TOKEN@github.com/ + YOUR-USERNAME + YOUR-REPOSITORY.git

Using SSH Keys Instead (Recommended)

Generate SSH key pair. To securely push changes without typing a token every time, it’s common to set up SSH keys. If you haven’t already, generate an SSH key pair: ssh-keygen -t ed25519 -C "your_email@example.com". This generates a private (~/.ssh/id_ed25519) and a public key (~/.ssh/id_ed25519.pub).
Add the public key to your GitHub account: Go to your GitHub account under Settings, navigate to SSH and GPG Keys, under Security on the left sidebar, click on the New SSH Key button and copy/paste the contents of your public key (~/.ssh/id_ed25519.pub).
Set the remote URL with SSH. Open your terminal and navigate to your local Git repository and set the remote URL for your existing repository: git remote set-url origin git@github.com:YOUR-USERNAME/YOUR-REPOSITORY.git
Clone a private repository with SSH keys: git clone git@github.com:YOUR-USERNAME/YOUR-REPOSITORY.git

Pushing to Main branch

After configuring SSH or personal access tokens, you can push: git push -u origin main. This command sets origin/main as the tracking branch for your local main repository.

Using .gitignore

The .gitignore file is a special file used in Git repositories to specify which files and directories should be ignored by Git (e.g., node_modules/, .env, .DS_Store Thumbs.db).

# Python build artifacts are files and directories created during the...
# build, packaging, and installation process of Python projects.
__pycache__
venv # Virtual environment

# Credentials include sensitive information like API keys,...
# passwords, database connection strings, and other secrets.
.env # Often used to store environment variables.

# Operating systems often create hidden files or folders for storing metadata, system preferences, or temporary files.
.DS_Store # (macOS) OS-specific files
Thumbs.db # (Windows)

The .gitignore file only prevents untracked files from being added to the repository. It doesn't remove files that were already tracked automatically.

To remove these files from your GitHub repository while keeping them on your local machine, follow these steps:

# Remove the files from Git's index without deleting them locally:
git rm --cached -r docs Espanso/base.yml Espanso/myespanso.json KeePassXC
# The option --cached keeps the files locally but removes them from Git tracking.

# Commit this removal:
git commit -m "Remove ignored files from repository"

# Push changes to GitHub:
git push origin main

Now the files no longer appear in the repository, but they remain on your local machine.

NixOS & git