The same concepts used for [AniNIX::Foundation](https://foundation.aninix.net/)'s revision control of code can be used for user home folders.
To create this tracking, use the following steps to create a read-write bare Git repo.
git init --bare
git clone .gitbare test && mv test/.git . && rmdir test
To pull these configs to any downstream system, do the following:
git clone $repo
cd $(ls -1tr | tail -n 1)
for item in $(ls -1a); do mv "$item" ..; done
You will need to set up the file tracking below -- `git status` at this point will report lots of files that you probably won't want to track, like browser cache, temporary files, and large document files that are better backed up outside revision control.
# File tracking
You will need the following .gitignore added to your repo. This will track SSH keys and config, PGP keys, Weechat config, bash config, git config, TMUX config, scripts, Vim config, and a password-store folder for KeePass or like password databases.
Other files are excluded for keeping the repo small enough to be cloned to a smartphone, but they can easily be added if so chosen.
# Ignore normal files
# Value of Local Branches
Some elements, like Git, use default identities for their operation. A local branch can be created at that site to update configurations that need to be site-specific -- if this data shouldn't be moved offsite, the branch needn't be pushed to the remote and can instead be cloned from a backup system directly.
There are some caveats to consider when using this policy.
## Cloud and Keys
Because this system captures SSH keys, PGP keys, and password databases, it is best [not stored in the cloud](/AniNIX/Wiki/src/branch/main/Policies/Design_Principles.md#user-content-physical-access). If you have to store it in the cloud, such as in Google Drive, GitHub, or AWS, you should look at [https://aninix.net/foundation/Aether AniNIX::Aether]'s source code for how to do strong encryption of a tarball of the repo, rather than committing directly to the cloud storage provider. This does, however, carry the intrinsic risk that flaws in the cryptography used can expose the keys to your identity! Don't use the cloud if you can avoid it.
## Large Files
Large files are difficult for revision control systems like this to handle -- they result in large differences for the revision control, which will lengthen clone times, branching, and such.
## SSH-Only Clones
For security, don't put these files onto a Webserver. SSH cloning is mandatory for security, and some ISP's may block residential IP's from getting SSH access.