When you live in a command line, configurations are a deeply personal thing. They are often crafted over years of experience, battles lost, lessons learned, advice followed, and ingenuity rewarded. When you are away from your own configurations, you are an orphaned refugee in unfamiliar and hostile surroundings. You feel clumsy and out of sorts. You are filled with a sense of longing to be back in a place you know. A place you built. A place where all the short-cuts have been worn bare by your own travels. A place you proudly call... `$HOME`.
As so many others, I started out with a repository of dotfiles and a few scripts to symbolically link them around my home directory. This quickly became inadequate and I looked for solutions elsewhere. I've used two excellent tools; [homeschick](https://github.com/andsens/homeshick), and [vcsh](https://github.com/RichiH/vcsh). These tools are great, and you should check them out to understand their strengths. However, I didn't find all of the features I personally wished for in a single tool. **yadm** was written with the following goals:
Eventually you will want to push the local repo to a remote.
yadm remote add origin <url>
yadm push -u origin master
#### If you have an existing remote repository
This `clone` will attempt to merge your existing repository, but if it fails, it will do a reset instead and you'll have to decide best on how resolve the differences.
yadm clone <url>
yadm status
## Strategies for alternate files on different systems
However, sometimes the type of file you are using doesn't allow for this type of logic. If a configuration can do an "include", you can include a specific alternate version using **yadm**. Consider these three files:
Configuring Git this way includes `.gitconfig.local` in the standard `.gitconfig`. **yadm** will automatically link the correct version based on the operation system. The bulk of your configurations can go in a single file, and you just put the exceptions in OS-specific files.
Below is an example of how **yadm** can be used to manage SSH configurations. The example demonstrates **yadm** directly managing the `config` file, managing a host-specific `authorized_keys` file, and storing the private SSH key as part of its encrypted files. This example assumes a typical working SSH configuration exists, and walks through the steps to bring it under **yadm**'s management.
First, the `config` file is simply added. This will cause the same `config` file to be used on other **yadm** managed hosts. The `authorized_keys` file needs to be host specific, so rename the file using the OS and hostname. After adding the renamed `authorized_keys##Linux.myhost`, **yadm** will automatically create the symlink for it. Last, the private key should be maintained in **yadm**'s encrypted files. Add a pattern to the `.yadm/encrypt` file which matches the private key. Then instruct **yadm** to encrypt all files matching the patterns found in `.yadm/encrypt`. Notice that the **yadm** repository is not tracking the private key directly, rather it tracks the collection of encrypted files `.yadm/files.gpg`. When these changes are brought onto another host, using the `yadm decrypt` command will extract the files stored.
