Difference between revisions of "Dotfiles"

From ArchWiki
Jump to navigation Jump to search
m (Reverted edits by Larivact (talk) to last revision by Ambrevar)
Tag: Rollback
Line 7: Line 7:
 
{{Related|X resources}}
 
{{Related|X resources}}
 
{{Related articles end}}
 
{{Related articles end}}
User-specific application configuration is traditionally stored in so called [[Wikipedia:dotfile|dotfiles]] (files whose filename starts with a dot). It is common practice to track dotfiles with a [[version control system]] such as [[Git]] to keep track of changes and synchronize dotfiles across various hosts. There are various approaches to managing your dotfiles (e.g. directly tracking dotfiles in the home directory v.s. storing them in a subdirectory and symlinking/copying/generating files with a [[shell]] script or [[#Tools|a dedicated tool]]). Apart from explaining how to manage your dotfiles this article also contains [[#User repositories|a list of dotfile repositories]] from Arch Linux users.
+
This article collects user repositories with custom configuration files, commonly known as ''dotfiles''.
  
== Tracking dotfiles directly with Git ==
+
== Version control ==
  
The benefit of tracking dotfiles directly with Git is that it only requires [[Git]] and does not involve symlinks. The disadvantage is that [[#Host-specific configuration|host-specific configuration]] generally requires merging changes into multiple [[Git#Branching|branches]].
+
Managing dotfiles with [[version control system]]s such as [[Git]] helps to keep track of changes, share with others, and synchronize dotfiles across various hosts.
  
The simplest way to achieve this approach is to initialize a [[Git]] repository directly in your home directory and ignoring all files by default with a {{man|5|gitignore}} pattern of {{ic|*}}. This method however comes with two drawbacks: it can become confusing when you have other Git repositories in your home directory (e.g. if you forget to initialize a repository you suddenly operate on your dotfile repository) and you can no longer easily see which files in the current directory are untracked (because they are ignored).
+
=== Using gitignore ===
  
An alternative method without these drawbacks is the "bare repository and alias method" popularized by [https://news.ycombinator.com/item?id=11070797 this Hacker News comment], which just takes three commands to set up:
+
Keeping a [https://git-scm.com/book/en/v2/Git-Basics-Getting-a-Git-Repository 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 {{man|1|git-add}}.
  
$ git init --bare ~/.dotfiles
+
To prevent untracked files (appearing in commits and removed by {{man|1|git-clean}}), first exclude all files with {{man|5|gitignore}}:
$ alias config='/usr/bin/git --git-dir=$HOME/.dotfiles/ --work-tree=$HOME'
 
$ config config status.showUntrackedFiles no
 
  
You can then manage your dotfiles with the created [[alias]].
+
{{hc|~/.git/info/exclude|
 +
*}}
  
{{Tip|To avoid accidentally commiting confidential information, see [[Git#Filtering confidential information]].}}
+
Then use {{ic|git add -f}}, for example:
  
== Host-specific configuration ==
+
$ git add -f ~/.config/*
  
A common problem with synchronizing dotfiles across various machines is host-specific configuration.
+
And commit the changes with {{man|1|git-commit}}:
  
With [[Git]] this can be solved 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; when shared configuration is modified in the master branch, the per-machine branches need to be rebased on top of the updated master.
+
$ git commit -a
  
In configuration scripts like [[Command-line shell#Configuration files|shell configuration files]] conditional logic can be used. For example, [[Bash]] scripts (i.e. {{ic|.bashrc}}) can apply different configuration depending on the machine name (or type, custom variable, etc.):
+
{{Tip|To avoid accidentally commiting confidential information, see [[Git#Filtering confidential information]].}}
 
 
if <nowiki>[[ "$(hostname)" == "archlaptop" ]];</nowiki> then
 
    # laptop specific commands here
 
else
 
    # desktop or server machine commands
 
fi
 
  
Similar can also be achieved with [[.Xresources]].[https://jnrowe.github.io/articles/tips/Sharing_Xresources_between_systems.html]
+
=== Other tools ===
  
If you find rebasing Git branches too cumbersome, you may want to use a [[#Tools|tool]] that supports ''file grouping'', or if even greater flexibility is desired, a tool that does ''processing''.
+
* {{App|dotdrop|A tool to manage your dotfiles across different hosts and saving them to git without duplicates.|https://github.com/deadc0de6/dotdrop|{{AUR|dotdrop}}}}
 +
* {{App|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|{{AUR|dotfiles}}}}
 +
* {{App|dotgit|A comprehensive solution to managing your dotfiles.|http://github.com/Cube777/dotgit|{{AUR|dotgit}}}}
 +
* {{App|dots|A portable tool for managing a single set of dotfiles in an organized fashion.|https://github.com/EvanPurkhiser/dots|{{AUR|dots-manager}}}}
 +
* {{App|[[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/|{{Pkg|etckeeper}}}}
 +
* {{App|GNU Stow|Can be used to symlink dotfiles from a repository into the $HOME tree. See [http://brandon.invergo.net/news/2012-05-26-using-gnu-stow-to-manage-your-dotfiles.html] for more information.|http://www.gnu.org/software/stow/|{{Pkg|stow}}}}
 +
* {{App|homeshick|git dotfiles synchronizer written in bash.|https://github.com/andsens/homeshick|{{AUR|homeshick-git}}}}
 +
* {{App|homesick|Your home directory is your castle. Don't leave your dotfiles behind.|https://github.com/technicalpickles/homesick|{{AUR|homesick}}}}
 +
* {{App|mackup|a small Python utitlity to keep your application settings in sync.|https://github.com/lra/mackup|{{AUR|mackup}}}}
 +
* {{App|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|{{AUR|pearl-git}}}}
 +
* {{App|rcm|Can be used to symlink dotfiles from a repository into the $HOME tree.|https://github.com/thoughtbot/rcm|{{AUR|rcm}}}}
 +
* {{App|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|{{AUR|vcsh}}}}
 +
* {{App|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|{{AUR|yadm-git}}}}
  
== Tools ==
+
=== Maintaining dotfiles across multiple machines ===
  
;File grouping
+
{{Style|This section needs a rewrite}}
:How configuration files can be grouped to configuration groups (also called profiles or packages).
 
;Processing
 
:Some tools process configuration files to allow them to be customized depending on the host.
 
  
{| class="wikitable sortable" style="text-align:center;"
+
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.
! Name !! Package !! Written in !! File grouping !! Processing
 
|-
 
! [https://deadc0de.re/dotdrop/ dotdrop]
 
| {{AUR|dotdrop}} || Python || configuration file || Jinja2
 
|-
 
! [https://github.com/jbernard/dotfiles dotfiles]
 
| {{AUR|dotfiles}} || Python || {{Grey|[https://github.com/jbernard/dotfiles/pull/24 No]}} || {{Grey|No}}
 
|-
 
! [https://github.com/EvanPurkhiser/dots Dots]
 
| {{AUR|dots-manager}} || Python || directory-based || custom append points
 
|-
 
! [https://www.gnu.org/software/stow/ GNU Stow]
 
| {{Pkg|stow}} || Perl || directory-based[http://brandon.invergo.net/news/2012-05-26-using-gnu-stow-to-manage-your-dotfiles.html] || {{Grey|No}}
 
|-
 
! [https://github.com/lra/mackup Mackup]
 
| {{AUR|mackup}} || Python || automatic per application || {{Grey|No}}
 
|-
 
! [https://github.com/darkfeline/mir.qualia mir.qualia]
 
| {{AUR|mir.qualia}} || Python || {{Grey|No}} || custom blocks
 
|-
 
! [https://github.com/thoughtbot/rcm rcm]
 
| {{AUR|rcm}} || Perl || directory-based (by host or tag) || {{Grey|No}}
 
|}
 
  
=== Tools wrapping Git ===
+
The drawback on having some of the configuration files in multiple branches is that you have to remember to maintain and synchronize changes. Use conditional logic to minimize the number of machine specific files. For example, bash scripts (i.e. {{ic|.bashrc}}) can apply different configuration depending on the machine name (or type, custom variable, etc.):
  
If you are uncomfortable with [[Git]], you may want to use one of these tools, which abstract the version control system away (more or less).
+
if <nowiki>[[ "$(uname -n)" == "archlaptop" ]];</nowiki> then
 
+
    # laptop specific commands here
{| class="wikitable sortable" style="text-align:center;"
+
else
! Name !! Package !! Written in !! File grouping !! Processing
+
    # desktop or server machine commands
|-
+
fi
! [https://github.com/kobus-v-schoor/dotgit dotgit]
 
| {{AUR|dotgit}} || Bash || filename-based || {{Grey|No}}
 
|-
 
! [https://github.com/andsens/homeshick homeshick]
 
| {{AUR|homeshick-git}} || Bash || repository-wise || {{Grey|No}}
 
|-
 
! [https://github.com/technicalpickles/homesick homesick]
 
| {{AUR|homesick}} || Ruby || repository-wise || {{Grey|No}}
 
|-
 
! [https://github.com/pearl-core/pearl Pearl]
 
| {{AUR|pearl-git}} || Bash || repository-wise || {{Grey|No}}
 
|-
 
! [https://github.com/RichiH/vcsh vcsh]
 
| {{AUR|vcsh}} || Shell || repository-wise || {{Grey|No}}
 
|-
 
! [https://thelocehiliosan.github.io/yadm/ yadm]<sup>1)</sup>
 
| {{AUR|yadm-git}} || Shell || filename-based<br>(by class, OS, hostname & user) [https://thelocehiliosan.github.io/yadm/docs/alternates] || Jinja2<br>(optional)[https://thelocehiliosan.github.io/yadm/docs/alternates#jinja-templates]
 
|}
 
  
# Supports encryption of confidential files with [[GPG]].[https://thelocehiliosan.github.io/yadm/docs/encryption]
+
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.
  
== User repositories ==
+
== Repositories ==
  
 
{| class="wikitable sortable" style="text-align:center"
 
{| class="wikitable sortable" style="text-align:center"

Revision as of 15:28, 27 January 2019

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
Tip: To avoid accidentally commiting confidential information, see Git#Filtering confidential information.

Other tools

  • dotdrop — A tool to manage your dotfiles across different hosts and saving them to git without duplicates.
https://github.com/deadc0de6/dotdrop || dotdropAUR
  • 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 || dotfilesAUR
  • dotgit — A comprehensive solution to managing your dotfiles.
http://github.com/Cube777/dotgit || dotgitAUR
  • dots — A portable tool for managing a single set of dotfiles in an organized fashion.
https://github.com/EvanPurkhiser/dots || dots-managerAUR
  • 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-gitAUR
  • homesick — Your home directory is your castle. Don't leave your dotfiles behind.
https://github.com/technicalpickles/homesick || homesickAUR
  • mackup — a small Python utitlity to keep your application settings in sync.
https://github.com/lra/mackup || mackupAUR
  • 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-gitAUR
  • rcm — Can be used to symlink dotfiles from a repository into the $HOME tree.
https://github.com/thoughtbot/rcm || rcmAUR
  • 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 || vcshAUR
  • 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-gitAUR

Maintaining dotfiles across multiple machines

Tango-edit-clear.pngThis article or section needs language, wiki syntax or style improvements. See Help:Style for reference.Tango-edit-clear.png

Reason: This section needs 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.

The drawback on having some of the configuration files in multiple branches is that you have to remember to maintain and synchronize changes. Use conditional logic to minimize the number of machine specific files. For example, bash scripts (i.e. .bashrc) can apply different configuration depending on the machine name (or type, custom variable, etc.):

if [[ "$(uname -n)" == "archlaptop" ]]; then
    # laptop specific commands here
else
    # desktop or server machine commands
fi

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.

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 Eshell EXWM Emacs Emacs (Eshell) Emacs TRAMP + dtach EMMS conky/dzen mu4e Circe
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
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

See also