Remove unnecessary formatting
This commit is contained in:
parent
c8e8633639
commit
fd003e5b25
10 changed files with 96 additions and 96 deletions
|
@ -5,30 +5,30 @@ permalink: /docs/overview
|
|||
<a name=""></a><!-- Anchor "#" used at the ends of pagination -->
|
||||
> You've spent time tweaking your computing environment. Everything operates the
|
||||
way you want. That's fantastic! Then your hard drive fails, and the computer
|
||||
needs to be rebuilt. **yadm** can restore you configurations.
|
||||
needs to be rebuilt. yadm can restore you configurations.
|
||||
|
||||
> You get a new computer, and you want to recreate that environment. You
|
||||
probably want to keep both machines' configurations in sync. **yadm** can help
|
||||
probably want to keep both machines' configurations in sync. yadm can help
|
||||
you coordinate the configurations between your machines.
|
||||
|
||||
> You begin experimenting with new changes to your configurations, and now
|
||||
everything is broken. **yadm** can help you determine what changed or simply
|
||||
everything is broken. yadm can help you determine what changed or simply
|
||||
revert all of your changes.
|
||||
|
||||
**yadm** is like having a version of Git, that only operates on your dotfiles.
|
||||
If you know how to use Git, you already know how to use yadm.
|
||||
yadm is like having a version of Git, that only operates on your dotfiles.
|
||||
If you know how to use Git, you already know how to use yadm.
|
||||
|
||||
* It doesn't matter if your current directory is another Git-managed repository
|
||||
* You don't have to move your dotfiles, or have them symlinked from another
|
||||
location.
|
||||
* **yadm** automatically inherits all of Git's features, allowing you to branch,
|
||||
* yadm automatically inherits all of Git's features, allowing you to branch,
|
||||
merge, rebase, use submodules, etc.
|
||||
|
||||
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 tried other tools, but I
|
||||
didn't find all of the features I personally wished for in a single tool. This
|
||||
led to **yadm** being written with the following goals:
|
||||
led to yadm being written with the following goals:
|
||||
|
||||
* Use a single repository
|
||||
* Few dependencies
|
||||
|
@ -36,6 +36,6 @@ led to **yadm** being written with the following goals:
|
|||
* Ability to encrypt and track confidential files
|
||||
* Stay out of the way and let Git do what it's good at
|
||||
|
||||
Follow these links to [install](install) **yadm**
|
||||
Follow these links to [install](install) yadm
|
||||
or
|
||||
learn some simple steps for [getting started](getting_started) with **yadm**.
|
||||
learn some simple steps for [getting started](getting_started) with yadm.
|
||||
|
|
|
@ -6,7 +6,7 @@ permalink: /docs/install
|
|||
|
||||
## OSX
|
||||
|
||||
**yadm** can be installed using [Homebrew](https://github.com/Homebrew/homebrew).
|
||||
yadm can be installed using [Homebrew](https://github.com/Homebrew/homebrew).
|
||||
|
||||
```
|
||||
brew install yadm
|
||||
|
@ -18,11 +18,11 @@ Several yum repositories are on Copr. Follow this link for [repositories and ins
|
|||
|
||||
## Ubuntu/Debian
|
||||
|
||||
A version of **yadm** is available via standard package repositories. Use `apt-get` to install.
|
||||
A version of yadm is available via standard package repositories. Use `apt-get` to install.
|
||||
|
||||
## Arch Linux
|
||||
|
||||
**yadm** is available in the Arch User Repos and can be installed with AUR helper or Makepkg.
|
||||
yadm is available in the Arch User Repos and can be installed with AUR helper or Makepkg.
|
||||
|
||||
```
|
||||
yaourt -S yadm-git
|
||||
|
@ -30,7 +30,7 @@ yaourt -S yadm-git
|
|||
|
||||
## Gentoo Linux
|
||||
|
||||
**yadm** is available in the main gentoo portage tree, simply use `emerge` to install it.
|
||||
yadm is available in the main gentoo portage tree, simply use `emerge` to install it.
|
||||
|
||||
```
|
||||
emerge -atv app-admin/yadm
|
||||
|
@ -38,7 +38,7 @@ emerge -atv app-admin/yadm
|
|||
|
||||
## Void Linux
|
||||
|
||||
**yadm** is available in the official repository, simply use `xbps-install` to install it.
|
||||
yadm is available in the official repository, simply use `xbps-install` to install it.
|
||||
|
||||
```
|
||||
xbps-install yadm
|
||||
|
@ -46,7 +46,7 @@ xbps-install yadm
|
|||
|
||||
## FreeBSD
|
||||
|
||||
**yadm** is available in the FreeBSD ports. Use `pkg` to install it from a prebuilt binary package:
|
||||
yadm is available in the FreeBSD ports. Use `pkg` to install it from a prebuilt binary package:
|
||||
|
||||
```
|
||||
pkg install yadm
|
||||
|
@ -54,7 +54,7 @@ pkg install yadm
|
|||
|
||||
## Download
|
||||
|
||||
You *can* simply download the **yadm** script and put it into your `$PATH`. Something like this:
|
||||
You *can* simply download the yadm script and put it into your `$PATH`. Something like this:
|
||||
|
||||
```
|
||||
curl -fLo /usr/local/bin/yadm https://github.com/TheLocehiliosan/yadm/raw/master/yadm && chmod a+x /usr/local/bin/yadm
|
||||
|
@ -64,7 +64,7 @@ Of course, you can change the file paths above to be appropriate for your `$PATH
|
|||
|
||||
## Clone
|
||||
|
||||
You might wish to clone the **yadm** project and symlink `yadm` into your
|
||||
You might wish to clone the yadm project and symlink `yadm` into your
|
||||
`$PATH`.
|
||||
|
||||
```
|
||||
|
@ -72,13 +72,13 @@ git clone https://github.com/TheLocehiliosan/yadm.git ~/.yadm-project
|
|||
ln -s ~/.yadm-project/yadm ~/bin/yadm
|
||||
```
|
||||
|
||||
Now you can pull the latest updates to **yadm** using Git. Again, adjust the
|
||||
Now you can pull the latest updates to yadm using Git. Again, adjust the
|
||||
file paths above to be appropriate for your `$PATH` and situation.
|
||||
|
||||
## Submodule
|
||||
|
||||
If you are comfortable with how Git submodules work, another option is to add
|
||||
the **yadm** project as a submodule and symlink `yadm` into your `$PATH`.
|
||||
the yadm project as a submodule and symlink `yadm` into your `$PATH`.
|
||||
|
||||
```
|
||||
cd ~
|
||||
|
@ -95,7 +95,7 @@ When using submodules, you need to initialize them each time you do a fresh
|
|||
yadm submodule update --init --recursive
|
||||
```
|
||||
|
||||
Updating to a newer version of **yadm** would use commands similar to this.
|
||||
Updating to a newer version of yadm would use commands similar to this.
|
||||
|
||||
```
|
||||
cd ~/.yadm-project
|
||||
|
|
|
@ -2,7 +2,7 @@
|
|||
title: "Getting Started"
|
||||
permalink: /docs/getting_started
|
||||
---
|
||||
Starting out with **yadm** should be just a few easy steps.
|
||||
Starting out with yadm should be just a few easy steps.
|
||||
|
||||
### If you don't currently have a repository
|
||||
Start out with an empty local repository
|
||||
|
@ -17,7 +17,7 @@ Eventually you will want to push the local repo to a remote.
|
|||
yadm push -u origin master
|
||||
|
||||
### If you have an existing remote repository
|
||||
Clone your existing repo using **yadm**.
|
||||
Clone your existing repo using yadm.
|
||||
|
||||
yadm clone <url>
|
||||
yadm status
|
||||
|
|
|
@ -3,23 +3,23 @@ title: "Common Commands"
|
|||
permalink: /docs/common_commands
|
||||
---
|
||||
Most of these operations will look like Git commands; because they are.
|
||||
**yadm** wraps Git, allowing it to perform all of Git's operations. The
|
||||
yadm wraps Git, allowing it to perform all of Git's operations. The
|
||||
difference is your `$HOME` directory becomes the working directory, and you can
|
||||
run the commands from any directory.
|
||||
|
||||
Commands below which are special to **yadm** are denoted with
|
||||
Commands below which are special to yadm are denoted with
|
||||
<i class="fa fa-fw fa-asterisk" aria-hidden="true"></i>,
|
||||
and those which are passed directly through to Git are denoted with
|
||||
<i class="fab fa-fw fa-git-square" aria-hidden="true"></i>.
|
||||
|
||||
<i class="fa fa-fw fa-asterisk" aria-hidden="true"></i> `man yadm`
|
||||
: Display **yadm**'s
|
||||
: Display yadm's
|
||||
[manual](https://github.com/TheLocehiliosan/yadm/blob/master/yadm.md).
|
||||
|
||||
<i class="fab fa-fw fa-git-square" aria-hidden="true"></i> `yadm status`
|
||||
: Show the repository status; added, changed, removed files. Because a `$HOME`
|
||||
directory often more than only dotfiles, by default
|
||||
**yadm** ignores untracked files when displaying status.
|
||||
yadm ignores untracked files when displaying status.
|
||||
|
||||
<i class="fab fa-fw fa-git-square" aria-hidden="true"></i> `yadm push`, `yadm fetch`
|
||||
: Send or retrive commits to/from your remote repository .
|
||||
|
@ -36,7 +36,7 @@ message or add staged changes to the previous commit.
|
|||
commit.
|
||||
|
||||
<i class="fa fa-fw fa-asterisk" aria-hidden="true"></i> `yadm list -a`
|
||||
: Print a list of files managed by **yadm**. The -a option will cause all managed
|
||||
: Print a list of files managed by yadm. The -a option will cause all managed
|
||||
files to be listed. Otherwise, the list will only include files from the
|
||||
current directory or below.
|
||||
|
||||
|
|
|
@ -5,11 +5,11 @@ permalink: /docs/bootstrap
|
|||
|
||||
Often there is more to set up once your dotfiles repository has been cloned. For
|
||||
example, if your repository has submodules, you may wish to initialize them. On
|
||||
MacOS, you may wish to install **Homebrew** and process a `.Brewfile`. These types
|
||||
MacOS, you may wish to install Homebrew and process a `.Brewfile`. These types
|
||||
of additional steps are generally referred to as "bootstrapping".
|
||||
|
||||
Though everyone may have a different set of bootstrap operations they need to
|
||||
perform, **yadm** has a standard command for executing them.
|
||||
perform, yadm has a standard command for executing them.
|
||||
|
||||
yadm bootstrap
|
||||
|
||||
|
@ -17,7 +17,7 @@ This command will execute the program named `$HOME/.yadm/bootstrap`. You must
|
|||
provide this program yourself, and it must be made executable. But those are the
|
||||
only constraints.
|
||||
|
||||
After **yadm** successfully clones a repository, if there is a bootstrap program
|
||||
After yadm successfully clones a repository, if there is a bootstrap program
|
||||
available, it will offer to run it for you.
|
||||
|
||||
Found .yadm/bootstrap
|
||||
|
@ -37,7 +37,7 @@ in Bash, but you can use any executable file as a bootstrap.
|
|||
|
||||
### Initialize submodules
|
||||
|
||||
If you've added repositories as submodules for the **yadm** repository, you can
|
||||
If you've added repositories as submodules for the yadm repository, you can
|
||||
initialize them after a successful clone.
|
||||
|
||||
```bash
|
||||
|
@ -105,10 +105,10 @@ if [ -f "$HOME/.terminfo/custom.terminfo" ]; then
|
|||
fi
|
||||
```
|
||||
|
||||
### Update the **yadm** repo origin URL
|
||||
### Update the yadm repo origin URL
|
||||
|
||||
You might initially clone your repo using `https`, but ssh configurations may be
|
||||
available after cloning. If so, you could update the **yadm** repo origin to use
|
||||
available after cloning. If so, you could update the yadm repo origin to use
|
||||
`ssh` instead.
|
||||
|
||||
```bash
|
||||
|
@ -120,9 +120,9 @@ yadm remote set-url origin "git@github.com:MyUser/dotfiles.git"
|
|||
|
||||
### Install [vim](http://www.vim.org/) plugins managed with [vim-plug](https://github.com/junegunn/vim-plug)
|
||||
|
||||
**vim-plug** can be used in your `.vimrc` to enable plugins. The example here will
|
||||
automatically download **vim-plug** and run the `:PlugInstall` command if
|
||||
**vim-plug** is missing when **vim** starts.
|
||||
vim-plug can be used in your `.vimrc` to enable plugins. The example here will
|
||||
automatically download vim-plug and run the `:PlugInstall` command if
|
||||
vim-plug is missing when vim starts.
|
||||
|
||||
```vim
|
||||
" download vim-plug if missing
|
||||
|
@ -154,7 +154,7 @@ endif
|
|||
```
|
||||
|
||||
You can enhance this scheme by having your bootstrap program initialize
|
||||
**vim-plug** when you clone, instead of when you first run **vim**. This example
|
||||
vim-plug when you clone, instead of when you first run vim. This example
|
||||
will install any new plugins, and also remove any plugins now deleted from your
|
||||
`.vimrc`.
|
||||
|
||||
|
|
|
@ -10,9 +10,9 @@ features and strategies for dealing with those occasions.
|
|||
## Symlink alternates
|
||||
|
||||
It can be useful to have an automated way of choosing an alternate version of a
|
||||
file for a different operating system, host, or user. **yadm** implements a
|
||||
file for a different operating system, host, or user. yadm implements a
|
||||
feature which will automatically create a symbolic link to the appropriate
|
||||
version of a file, as long as you follow a specific naming convention. **yadm** can
|
||||
version of a file, as long as you follow a specific naming convention. yadm can
|
||||
detect files with names ending in:
|
||||
|
||||
| `##` | Default file linked |
|
||||
|
@ -24,10 +24,10 @@ detect files with names ending in:
|
|||
| `##OS.HOSTNAME` | Matching OS & Hostname |
|
||||
| `##OS.HOSTNAME.USER` | Matching OS, Hostname, & User |
|
||||
|
||||
If there are any files managed by **yadm**'s repository, or listed in
|
||||
If there are any files managed by yadm's repository, or listed in
|
||||
`$HOME/.yadm/encrypt`, which match this naming convention, symbolic links will
|
||||
be created for the most appropriate version. This may best be demonstrated by
|
||||
example. Assume the following files are managed by **yadm**'s repository:
|
||||
example. Assume the following files are managed by yadm's repository:
|
||||
|
||||
$HOME/path/example.txt##
|
||||
$HOME/path/example.txt##Work
|
||||
|
@ -38,12 +38,12 @@ example. Assume the following files are managed by **yadm**'s repository:
|
|||
$HOME/path/example.txt##Linux.host1
|
||||
$HOME/path/example.txt##Linux.host2
|
||||
|
||||
If running on a Macbook named `host2`, **yadm** will create a symbolic link which
|
||||
If running on a Macbook named `host2`, yadm will create a symbolic link which
|
||||
looks like this:
|
||||
|
||||
`$HOME/path/example.txt` → `$HOME/path/example.txt##Darwin.host2`
|
||||
|
||||
However, on another Macbook named `host3`, **yadm** will create a symbolic link
|
||||
However, on another Macbook named `host3`, yadm will create a symbolic link
|
||||
which looks like this:
|
||||
|
||||
`$HOME/path/example.txt` → `$HOME/path/example.txt##Darwin`
|
||||
|
@ -71,7 +71,7 @@ then no link will be created.
|
|||
| **HOSTNAME** by running `hostname` and removing any domain.
|
||||
| **USER** by running `id -u -n`.
|
||||
|
||||
**yadm** will automatically create these links by default. This can be disabled using the `yadm.auto-alt` configuration. Even if disabled, links can be manually created by running **yadm** alt.
|
||||
yadm will automatically create these links by default. This can be disabled using the `yadm.auto-alt` configuration. Even if disabled, links can be manually created by running yadm alt.
|
||||
|
||||
## Wildcards
|
||||
|
||||
|
@ -87,7 +87,7 @@ $HOME/path/example.txt##%.%.harvey
|
|||
|
||||
Class is a special value which is stored locally on each host (inside the local
|
||||
repository). To use alternate symlinks using `CLASS`, you must set the value of
|
||||
class using the configuration `local.class`. This is set like any other **yadm**
|
||||
class using the configuration `local.class`. This is set like any other yadm
|
||||
configuration—with the `yadm config` command. The following sets the `CLASS` to
|
||||
be "Work".
|
||||
|
||||
|
@ -100,7 +100,7 @@ overridden using the configuration options `local.os`, `local.hostname`, and
|
|||
## Jinja templates
|
||||
|
||||
If the `envtpl` command is available, Jinja templates will also be processed to
|
||||
create or overwrite real files. **yadm** will treat files ending in `##yadm.j2`
|
||||
create or overwrite real files. yadm will treat files ending in `##yadm.j2`
|
||||
as Jinja templates. During processing, the following variables are set according
|
||||
to the rules explained in the [Alternates section](alternates#symlink-alternates):
|
||||
|
||||
|
@ -110,7 +110,7 @@ to the rules explained in the [Alternates section](alternates#symlink-alternates
|
|||
* `YADM_USER`
|
||||
|
||||
In addition `YADM_DISTRO` is exposed as the value of `lsb_release -si` if
|
||||
**lsb_release** is locally available.
|
||||
lsb_release is locally available.
|
||||
|
||||
For example, a file named `whatever##yadm.j2` with the following content
|
||||
|
||||
|
@ -168,7 +168,7 @@ fi
|
|||
|
||||
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:
|
||||
alternate version using yadm. Consider these three files:
|
||||
|
||||
`.gitconfig`
|
||||
|
||||
|
@ -197,6 +197,6 @@ 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
|
||||
`.gitconfig`. yadm will automatically link the correct version based on the
|
||||
operating system. The bulk of your configurations can go in a single file, and
|
||||
you just put the exceptions in OS-specific files.
|
||||
|
|
|
@ -4,7 +4,7 @@ permalink: /docs/encryption
|
|||
---
|
||||
It can be useful to manage confidential files, like SSH keys, across multiple
|
||||
systems. However, doing so would put plain text data into a Git repository,
|
||||
which often resides on a public system. **yadm** implements a feature which can
|
||||
which often resides on a public system. yadm implements a feature which can
|
||||
make it easy to encrypt and decrypt a set of files so the encrypted version can
|
||||
be maintained in the Git repository. This feature will only work if the gpg
|
||||
command is available.
|
||||
|
@ -19,7 +19,7 @@ To use this feature, a list of patterns must be created and saved as
|
|||
The `yadm encrypt` command will find all files matching the patterns, and
|
||||
prompt for a password. Once a password has confirmed, the matching files will be
|
||||
encrypted and saved as `$HOME/.yadm/files.gpg`. The patterns and files.gpg
|
||||
should be added to the **yadm** repository so they are available across multiple
|
||||
should be added to the yadm repository so they are available across multiple
|
||||
systems.
|
||||
|
||||
yadm add .yadm/encrypt
|
||||
|
|
|
@ -8,11 +8,11 @@ permalink: /docs/faq
|
|||
|
||||
### I just cloned my repository and conflicting data was overwritten. Why?
|
||||
|
||||
Prior to cloning your repository, files managed by **yadm** already existed. For
|
||||
Prior to cloning your repository, files managed by yadm already existed. For
|
||||
example, imagine you are logged into a system and `$HOME/.bash_profile` already
|
||||
exists. If you then clone your **yadm** repository—which also contains
|
||||
exists. If you then clone your yadm repository—which also contains
|
||||
`.bash_profile`—then you will likely get a conflict. Since version 1.07,
|
||||
**yadm** responds by "stashing" these conflicts. To view the stashed data, you can
|
||||
yadm responds by "stashing" these conflicts. To view the stashed data, you can
|
||||
run `yadm stash show -p` from within your `$HOME` directory. If you want to
|
||||
restore the stashed data, you can run `yadm stash apply` from within your
|
||||
`$HOME` directory.
|
||||
|
@ -22,7 +22,7 @@ restore the stashed data, you can run `yadm stash apply` from within your
|
|||
Whenever a Git commit is generated, Git requires information about the author of
|
||||
the commit. This can be configured via the `git config` command. Usually the
|
||||
best approach is to configure this information globally, and then manage your
|
||||
global Git configuration via **yadm**. This allows the configuration to follow
|
||||
global Git configuration via yadm. This allows the configuration to follow
|
||||
you wherever your dotfiles live.
|
||||
|
||||
```
|
||||
|
@ -32,20 +32,20 @@ git config --global "user.name" "Your Name"
|
|||
yadm add ~/.gitconfig
|
||||
```
|
||||
|
||||
However, if you want commits to your **yadm** repo to use a different author,
|
||||
you can configure these settings in the **yadm** repo itself.
|
||||
However, if you want commits to your yadm repo to use a different author,
|
||||
you can configure these settings in the yadm repo itself.
|
||||
|
||||
```
|
||||
yadm gitconfig "user.email" "alternate-email@domain"
|
||||
yadm gitconfig "user.name" "Alternate Name"
|
||||
```
|
||||
|
||||
Note: Configuring these settings directly in the **yadm** repo will require you
|
||||
Note: Configuring these settings directly in the yadm repo will require you
|
||||
to configure it each time you clone the repo.
|
||||
|
||||
### How can I display untracked files with a `yadm status` command?
|
||||
|
||||
By default, **yadm** is configured to ignore untracked files when displaying a
|
||||
By default, yadm is configured to ignore untracked files when displaying a
|
||||
status. You can use the `-u` paramter on the status command to alter how
|
||||
untracked files are treated. `-unormal` will show untracked files and
|
||||
directories.
|
||||
|
@ -55,7 +55,7 @@ yadm status -unormal
|
|||
```
|
||||
|
||||
If you want to change the default treatment, you can change this configuration
|
||||
on the **yadm** repository itself.
|
||||
on the yadm repository itself.
|
||||
|
||||
```
|
||||
yadm gitconfig --unset status.showUntrackedFiles
|
||||
|
@ -71,7 +71,7 @@ yadm add -u :/
|
|||
|
||||
(Starting with Git 2.0, the `:/` is not necessary)
|
||||
|
||||
### How can I change the URL of my remote **yadm** repository?
|
||||
### How can I change the URL of my remote yadm repository?
|
||||
|
||||
This is done the same way you change the URL of any Git repository.
|
||||
|
||||
|
@ -79,18 +79,18 @@ This is done the same way you change the URL of any Git repository.
|
|||
yadm remote set-url origin <NEW-URL>
|
||||
```
|
||||
|
||||
This could be useful if you manage your ssh keys in the **yadm** repository.
|
||||
This could be useful if you manage your ssh keys in the yadm repository.
|
||||
That could make it difficult to initially clone the repository using the `ssh`
|
||||
protocol. You can start by cloning the repository using the `https` protocol
|
||||
(and providing a password), and then change the repository's URL after you've
|
||||
decrypted your ssh keys.
|
||||
|
||||
### I've customized **yadm** configurations (stored in `~/.yadm/config`). Should I add that to my repository?
|
||||
### I've customized yadm configurations (stored in `~/.yadm/config`). Should I add that to my repository?
|
||||
|
||||
Certainly. That is a good way to carry your **yadm** configurations around (just
|
||||
Certainly. That is a good way to carry your yadm configurations around (just
|
||||
like the rest of your dotfiles).
|
||||
|
||||
### Can you point to any example **yadm** managed repositories?
|
||||
### Can you point to any example yadm managed repositories?
|
||||
|
||||
[This page](examples) contains some examples.
|
||||
|
||||
|
@ -108,10 +108,10 @@ clone your repository. Read [bootstrap](bootstrap) for more details.
|
|||
|
||||
## Encryption
|
||||
|
||||
### Can I use **yadm** without **gpg**?
|
||||
### Can I use yadm without gpg?
|
||||
|
||||
Of course. You only need `gpg` installed if you plan on using the
|
||||
encrypt/decrypt features. **yadm** will tell you if it is missing a dependency
|
||||
encrypt/decrypt features. yadm will tell you if it is missing a dependency
|
||||
for any command.
|
||||
|
||||
### Should I `yadm add` my `.yadm/encrypt` file?
|
||||
|
@ -123,13 +123,13 @@ you when you clone your repository.
|
|||
|
||||
No, you should not. Files you want encrypted should be added to the file
|
||||
`.yadm/files.gpg` using the `yadm encrypt` command. Then `.yadm/files.gpg`
|
||||
should be added to the **yadm** repository. This way, only an encrypted
|
||||
should be added to the yadm repository. This way, only an encrypted
|
||||
collection of those files are put into the repository. After cloning or updating
|
||||
your repository, you can use `yadm decrypt` to extract those files from
|
||||
`.yadm/files.gpg`. See the
|
||||
[encryption help](encryption) for more details.
|
||||
|
||||
### I modified an encrypted file, but **yadm** doesn't show any modifications. Why?
|
||||
### I modified an encrypted file, but yadm doesn't show any modifications. Why?
|
||||
|
||||
If you changed files which are matched by `.yadm/encrypt`, you must re-run `yadm
|
||||
encrypt` to generate a new version of `.yadm/files.gpg`. Then `.yadm/files.gpg`
|
||||
|
@ -139,17 +139,17 @@ can be added to a new commit.
|
|||
|
||||
If you get the error
|
||||
`command get_passphrase failed: Inappropriate ioctl for device`
|
||||
when running `yadm encrypt`, **gpg** is having trouble identifying the tty to
|
||||
use. The environment variable `GPG_TTY` can be used to help **gpg** out. Export
|
||||
when running `yadm encrypt`, gpg is having trouble identifying the tty to
|
||||
use. The environment variable `GPG_TTY` can be used to help gpg out. Export
|
||||
this variable to your shell in your login scripts.
|
||||
|
||||
```
|
||||
export GPG_TTY=$(tty)
|
||||
```
|
||||
|
||||
### Can I use **yadm** and **git-crypt**?
|
||||
### Can I use yadm and git-crypt?
|
||||
|
||||
There is an experimental version of **yadm** which can use **git-crypt**. You
|
||||
There is an experimental version of yadm which can use git-crypt. You
|
||||
can find it in the [git-crypt-support branch](
|
||||
https://github.com/TheLocehiliosan/yadm/commits/git-crypt-support
|
||||
). See the
|
||||
|
@ -159,27 +159,27 @@ https://github.com/TheLocehiliosan/yadm/commit/efb7fd16612fe650b1286f0c696696f41
|
|||
|
||||
## Comparisons
|
||||
|
||||
### How does **yadm** differ from **homeshick**?
|
||||
### How does yadm differ from homeshick?
|
||||
|
||||
**yadm** and **homeshick** are both written in Bash, with very limited
|
||||
dependencies. However, **homeshick** works by symlinking data from a repository
|
||||
working directory into your `$HOME` directory. **yadm** instead uses your
|
||||
`$HOME` directory _as_ its working directory. **homeshick** allows for multiple
|
||||
"castles" to be linked into `$HOME`, while **yadm** is designed to work with a
|
||||
single repository. **homeshick** requires you to change into the "castle"
|
||||
directory before performing any Git based commands. **yadm** allows you to
|
||||
perform operations regardless of your location. **yadm** also includes unique
|
||||
yadm and homeshick are both written in Bash, with very limited
|
||||
dependencies. However, homeshick works by symlinking data from a repository
|
||||
working directory into your `$HOME` directory. yadm instead uses your
|
||||
`$HOME` directory _as_ its working directory. homeshick allows for multiple
|
||||
"castles" to be linked into `$HOME`, while yadm is designed to work with a
|
||||
single repository. homeshick requires you to change into the "castle"
|
||||
directory before performing any Git based commands. yadm allows you to
|
||||
perform operations regardless of your location. yadm also includes unique
|
||||
features to encrypt private data, and symlink alternate versions of files based
|
||||
on OS type or hostname.
|
||||
|
||||
### How does **yadm** differ from **vcsh**?
|
||||
### How does yadm differ from vcsh?
|
||||
|
||||
**yadm** and **vcsh** both work as a filters for standard Git commands. Both
|
||||
yadm and vcsh both work as a filters for standard Git commands. Both
|
||||
also use your `$HOME` directory _as_ the repository's working directory.
|
||||
However, **vcsh** is designed to work with multiple repositories, **yadm**
|
||||
instead uses a single repository. **vcsh** requires you to specify which
|
||||
repository you want to operate on, while **yadm** only operates on one. If you
|
||||
want to use Git submodules, you _may_ have trouble using **vcsh**. This is
|
||||
However, vcsh is designed to work with multiple repositories, yadm
|
||||
instead uses a single repository. vcsh requires you to specify which
|
||||
repository you want to operate on, while yadm only operates on one. If you
|
||||
want to use Git submodules, you _may_ have trouble using vcsh. This is
|
||||
because only one repository can be the owner of the `.gitmodules` file.
|
||||
**yadm** also includes unique features to encrypt private data, and symlink
|
||||
yadm also includes unique features to encrypt private data, and symlink
|
||||
alternate versions of files based on OS type or hostname.
|
||||
|
|
|
@ -4,7 +4,7 @@ permalink: /docs/examples
|
|||
---
|
||||
<a name=""></a><!-- Anchor "#" used at the ends of pagination -->
|
||||
Need some inspiration? Here are some public dotfiles repositories managed by
|
||||
**yadm**. Drop me a line if you have a dotfiles repo you'd like added to this
|
||||
yadm. Drop me a line if you have a dotfiles repo you'd like added to this
|
||||
list.
|
||||
|
||||
* [Search github for repos tagged with `yadm`](https://github.com/search?q=topic%3Ayadm&type=Repositories)
|
||||
|
|
|
@ -36,10 +36,10 @@ feature_row:
|
|||
url: /docs/overview
|
||||
excerpt: '
|
||||
|
||||
If you know how to use Git, you already know how to use **yadm**.
|
||||
**yadm** helps you maintain a single repository of dotfiles, while keeping
|
||||
If you know how to use Git, you already know how to use yadm.
|
||||
yadm helps you maintain a single repository of dotfiles, while keeping
|
||||
them where they belong---in `$HOME`.
|
||||
Anything you can do with Git, you can do using **yadm**.
|
||||
Anything you can do with Git, you can do using yadm.
|
||||
|
||||
'
|
||||
- title: Alternate Files
|
||||
|
@ -51,7 +51,7 @@ feature_row:
|
|||
excerpt: '
|
||||
|
||||
Sometimes you need different configurations on different systems.
|
||||
**yadm** makes it possible to use alternate versions of files based on
|
||||
yadm makes it possible to use alternate versions of files based on
|
||||
the OS or hostname of the system.
|
||||
|
||||
'
|
||||
|
@ -64,7 +64,7 @@ feature_row:
|
|||
excerpt: '
|
||||
|
||||
Configurations occasionally include secrets such as passwords,
|
||||
encryption keys, or other sensitive information. **yadm** allows you to
|
||||
encryption keys, or other sensitive information. yadm allows you to
|
||||
add such files to an encrypted archive, which can be maintained
|
||||
alongside your other configurations.
|
||||
|
||||
|
@ -78,7 +78,7 @@ feature_row:
|
|||
excerpt: '
|
||||
|
||||
Define your own instructions to complete your dotfiles installation.
|
||||
If provided, **yadm** can execute your custom program immediately
|
||||
If provided, yadm can execute your custom program immediately
|
||||
following a successful clone.
|
||||
|
||||
'
|
||||
|
|
Loading…
Reference in a new issue