Dotfiles: Difference between revisions

Revision as of 17:47, 9 December 2018

This article collects user repositories with custom configuration files, commonly known as dotfiles.

Version control

Managing dotfiles with version control systems such as Git helps to keep track of changes, share with others, and synchronize dotfiles across various hosts.

Using gitignore

Keeping a git directory inside the home folder allows to directly keep track of changes. It is recommended to selectively add file contents to the index with git-add(1).

To prevent untracked files (appearing in commits and removed by git-clean(1)), first exclude all files with gitignore(5):

~/.git/info/exclude

Then use git add -f, for example:

$ git add -f ~/.config/*

And commit the changes with git-commit(1):

$ git commit -a

Other tools

dotdrop — A tool to manage your dotfiles across different hosts and saving them to git without duplicates.

https://github.com/deadc0de6/dotdrop || dotdrop^AUR

dotfiles — A tool to make managing your dotfile symlinks in $HOME easy, allowing you to keep all of them in a single directory.

https://github.com/jbernard/dotfiles || dotfiles^AUR

dotgit — A comprehensive solution to managing your dotfiles.

http://github.com/Cube777/dotgit || dotgit^AUR

dots — A portable tool for managing a single set of dotfiles in an organized fashion.

https://github.com/EvanPurkhiser/dots || dots-manager^AUR

etckeeper — Intended to version-control system-wide configuration in /etc. Works by keeping track of permissions and modes which version-control software often ignores. Can use various SCM systems as a backend. Hooks can auto-commit changes to the repository before a system-upgrade.

http://etckeeper.branchable.com/ || etckeeper

GNU Stow — Can be used to symlink dotfiles from a repository into the $HOME tree. See [1] for more information.

http://www.gnu.org/software/stow/ || stow

homeshick — git dotfiles synchronizer written in bash.

https://github.com/andsens/homeshick || homeshick-git^AUR

homesick — Your home directory is your castle. Don't leave your dotfiles behind.

https://github.com/technicalpickles/homesick || homesick^AUR

mackup — a small Python utitlity to keep your application settings in sync.

https://github.com/lra/mackup || mackup^AUR

Pearl — Package manager for dotfiles, plugins, programs and any form of code accessible via git. Allow to easily share and sync packages across systems and have them ready to work out of the box.

https://github.com/pearl-core/pearl || pearl-git^AUR

rcm — Can be used to symlink dotfiles from a repository into the $HOME tree.

https://github.com/thoughtbot/rcm || rcm^AUR

vcsh — Allows separating differents modules (e.g., Emacs config vs. zsh config) into individual repositories which can be maintained separately, as opposed to keeping all dotfiles in a single repository. Works with git only.

https://github.com/RichiH/vcsh || vcsh^AUR

yadm — Manages files across systems using a single Git repository. Provides a way to use alternate files on a specific OS or host. Supplies a method of encrypting confidential data so it can safely be stored in your repository.

https://github.com/TheLocehiliosan/yadm || yadm-git^AUR

Maintaining dotfiles across multiple machines

This article or section needs language, wiki syntax or style improvements. See Help:Style for reference.

Reason: This and the section below need a rewrite (Discuss in Talk:Dotfiles)

One way of maintaining dotfiles across various machines across various hosts while still allowing for per-host customizations, is by maintaining a master-branch for all shared configuration, while each individual machine has a machine-specific branch checked out. Host-specific configuration can be committed to the machine-specific branch; as shared configuration is added to the master-branch, the per-machine branches are then rebased on top of the updated master.

Another approach is to manage machine-specific configuration with tools based on template engines, e.g. qualia or Dotdrop. This approach requires less manual work and doesn't cause merge conflicts.

Confidential information

Occasionally, software may keep plain-text passwords in configuration files, as opposed to hooking into a keyring. In these cases, git clean-filters may be handy to avoid accidentally commiting confidential information. E. g., the following file assigns a filter to the file “some-dotfile”:

.gitattributes

some-dotfile filter=remove-pass

Whenever the file “some-dotfile” is checked into git, git will invoke the filter “remove-pass” on the file before checking it in. The filter must be defined in the git-configuration file, e. g.:

.git/config

[filter "remove-pass"]
clean = "sed -e 's/^password=.*/#password=TODO/'"

Repositories

Author	Shell (Shell framework)	WM / DE	Editor	Terminal	Multiplexer	Audio	Monitor	Mail	IRC
alfunx	zsh	awesome	vim	kitty	tmux	ncmpcpp/mpd	htop/lain	thunderbird
Ambrevar	zsh	awesome	emacs	rxvt-unicode		cmus	htop/vicious	mutt
awal	fish	i3	vim	st	tmux		i3status		The Lounge
ayekat	zsh	karuiwm	vim	rxvt-unicode	tmux	ncmpcpp/mpd	karuibar	mutt	irssi
bamos	zsh	i3/xmonad	vim/emacs	rxvt-unicode	tmux	mpv/cmus	conky/xmobar	mutt	ERC
brisbin33	zsh	xmonad	vim	rxvt-unicode	screen		dzen	mutt	irssi
BVollmerhaus	bash	i3-gaps	kakoune	rxvt-unicode			polybar	thunderbird
cinelli	zsh	dwm	vim	termite-git		pianobar	htop	mutt-kz	weechat
dikiaap	zsh	i3-gaps	neovim	alacritty	tmux		i3blocks
Earnestly	zsh	i3/orbment	vim/emacs	termite	tmux	mpd	conky	mutt	weechat
ErikBjare	zsh	xmonad/xfce4	vim	terminator	tmux		xfce4-panel		weechat
falconindy	bash	i3	vim	rxvt-unicode		ncmpcpp	conky	mutt
graysky	zsh	xfce4	vim	terminal		ncmpcpp	custom	thunderbird
hugdru	zsh	awesome	neovim	rxvt-unicode	tmux			thunderbird	weechat
insanum	bash	herbstluftwm	vim	evilvte	tmux		dzen	mutt-kz
jasonwryan	bash/zsh	dwm	vim	rxvt-unicode	tmux	ncmpcpp	custom	mutt	irssi
jdevlieghere	zsh	xmonad	vim	terminal	tmux		htop	mutt	weechat
jelly	zsh	i3	vim	termite	tmux	ncmpcpp		mutt-kz-git	weechat
maximbaz	zsh	i3-gaps	neovim	kitty			py3status	thunderbird
meskarune	bash	herbstluftwm	vim	rxvt-unicode	screen		conky		weechat
neersighted	zsh	i3	vim	rxvt-unicode	tmux	ncmpcpp	htop	mutt	irssi
OK100	bash	dwm	vim	rxvt-unicode		cmus	conky, dzen	mutt	weechat
pablox-cl	zsh (zplug)	gnome3	neovim	kitty
reisub0	bash	awesome	neovim	termite		mpd	conky
sistematico	zsh/fish/bash	i3-gaps	vim/nano	termite	tmux	ncmpcpp	polybar	mutt	weechat
sitilge	zsh	awesome	neovim	termite				thunderbird
swalladge	zsh/bash	i3	neovim/vim	termite	tmux	cmus	i3pystatus	mutt
SyfiMalik	zsh	i3	vim	rxvt-unicode	tmux	ncmpcpp/mpd	polybar	mutt	weechat
thiagowfx	bash/zsh	i3	vim/emacs	rxvt-unicode		ncmpcpp	i3blocks
unexist^{[dead link 2018-05-29]}	zsh	subtle	vim	rxvt-unicode		ncmpcpp		mutt	irssi
vodik	zsh	xmonad	vim	termite-git	tmux	ncmpcpp	custom	mutt	weechat
w0ng	zsh	dwm	vim	rxvt-unicode	tmux	ncmpcpp	custom	mutt	irssi
whitelynx	fish	i3	neovim	kitty			i3pystatus
Wintervenom	bash	herbstluftwm	vim	rxvt-unicode	screen	mpd (mpc-utils)	hlwm-dzen2	mutt	weechat
wolfcore	bash	dwm	vim	rxvt-unicode	tmux	cmus	custom		weechat
zendeavor	zsh	i3	vim	rxvt-unicode	tmux	ncmpcpp	i3status		weechat

@@ Line 51: / Line 51: @@
 {{Style|This and the section below need a rewrite}}
-[https://github.com/deadc0de6/dotdrop Dotdrop] helps you manage your dotfiles across multiple hosts/profiles. It stores all your dotfiles in a git repository (without duplicates) which is to be cloned on each host where your dotfiles have to be deployed. A list of dotfiles for each profile is defined through the configuration file and, using a template engine, [https://github.com/deadc0de6/dotdrop dotdrop] will generate the dotfiles exactly the way you need them for a specific profile. It also provides multiple additional features like the ability to store encrypted/private dotfiles, handle symlinks, associate actions to the deployment of specific dotfiles, etc.
+One way of maintaining dotfiles across various machines across various hosts while still allowing for per-host customizations, is by maintaining a master-branch for all shared configuration, while each individual machine has a machine-specific branch checked out. Host-specific configuration can be committed to the machine-specific branch; as shared configuration is added to the master-branch, the per-machine branches are then rebased on top of the updated master.
-Using git, one way of maintaining dotfiles across various machines across various hosts while still allowing for per-host customizations, is by maintaining a master-branch for all shared configuration, while each individual machine has a machine-specific branch checked out. Host-specific configuration can be committed to the machine-specific branch; as shared configuration is added to the master-branch, the per-machine branches are then rebased on top of the updated master.
+Another approach is to manage machine-specific configuration with tools based on template engines, e.g. [https://pypi.python.org/pypi/mir.qualia/ qualia] or [https://github.com/deadc0de6/dotdrop Dotdrop]. This approach requires less manual work and doesn't cause merge conflicts.
-Another approach is to put machine-specific configuration into specially commented blocks and to use [https://pypi.python.org/pypi/mir.qualia/ qualia] to automatically uncomment them on each machine.  This approach requires less manual work and doesn't cause merge conflicts.
 === Confidential information ===