Everything in Git? No Way
The article argues that Git is not suitable for managing everything, despite common advice to store configurations, notes, and other data in Git repositories. It highlights limitations such as Git's poor handling of binary files, large repositories, and non-linear workflows. The author suggests using more specialized tools for different types of data management.
Background
- This post pushes back on the trend of storing everything — config files, dotfiles, home directories, even entire operating system state — inside Git repositories. The author argues that Git is a tool for tracking source code, not a general-purpose file system or backup solution.
- The "everything in Git" movement gained traction among developers who use tools like `yadm`, `GNU Stow`, or plain bare repos to version-control their dotfiles. More ambitiously, projects like `NixOS` and `Guix` attempt to describe the entire system configuration declaratively and track it in Git.
- The author's main counterpoints: Git is bad at handling large binary files, it doesn't handle permissions well, it imposes a directed-acyclic-graph model unsuitable for many real-world workflows, and treating every machine state as a "commit" creates brittle, bloated repos that are hard to collaborate on.
- This is part of a longer-running debate in the developer community between "minimalism" (use the right tool for each job — e.g., `rsync` for backups, `etckeeper` for system config, `Syncthing` for sync) and "maximalism" (cram everything into a single Git monorepo for simplicity).