From ArchWiki
Revision as of 22:24, 12 January 2019 by Romstor (talk | contribs) (Rewrite: This is more of an FYI, not a strong opinion :-))
Jump to navigation Jump to search

Bare repository and alias method

Hi all, I'd love to expand this out to include the method coved in this HN discussion. The simplicity of it is rather beautiful and it keeps the tracking isolated from the rest of $HOME. Before I do that, I'm new here so don't want to just start making sizeable edits with some form of discussion. Can anyone see any advantages of the currently listed gitignore method that this does not provide? -- Kimburgess (talk)

So basically all it does is hide the untracked files in the commit window? IOW, a half-baked variant of Dotfiles#Using_gitignore which actually ignores the files instead of hiding them. One example where this is better if you end up running git clean. If the files are not ignored, they'd end up deleted. -- Alad (talk) 12:51, 26 December 2016 (UTC)
Almost. Although it's hiding rather than excluding, there's one important difference — the actual repo is in a sub directory, not the base of $HOME. This means when you're sitting in the $HOME tree, attempting to run any vanilla git commands will fail (as it's not a repo). This protects you a little, but also stops any git cruft from showing for users running with git aware prompt strings (i.e. showing current branch / state). You could add a wildcard exclusion to this method as well, but it would come with the tradeoff of losing visibility of what you don't have tracked in your dotfiles.--Kimburgess (talk) 23:52, 26 December 2016 (UTC)

Maintaining dotfiles across multiple machines

[Dotdrop]( is a tool that allows to easily manage dotfiles across multiple machines by leveraging the power of jinja2. It allows the use of symlink or not. It has multiple features that allows it to be usable for very different use cases but mostly focuses on that very use case: have a tool to manage your dotfiles across different hosts (and is very powerful at it). What about mentioning it in this section ? I'm biased as I'm the developer of the tool but maybe give it a try, you might like it. Deadc0de6 (talk) 14:28, 4 December 2018 (UTC)

Closing because of Special:Diff/558788. --Larivact (talk) 17:13, 12 January 2019 (UTC)


I am working on a rewrite at User:Larivact/drafts/Dotfiles. Comments are appreciated as replies here. --Larivact (talk) 18:33, 12 January 2019 (UTC)

Thank you for taking time to refactor the dotfiles section. I wanted to second the comment from Kimburgess above -- we should have a section or a link for an option to store files in the bare Git repository as described in that HN thread and The best way to store your dotfiles: A bare Git repository article. Just creating the .git in the home folder bit me a few times when I would accidentally check stuff in to my configuration repo by issuing git commands somewhere in the home folder structure. Putting it behind an alias makes it much safer and more transparent. Bare repo can also be put somewhere like ~/.local/share/dots.git/ as opposed to home directory -- another bonus as it follows the XDG Base Directory structure. Romstor (talk) 20:33, 12 January 2019 (UTC)
I agree that #Bare repository and alias method is superior and should be added, I'd even go further and make it our default recommendation. I am not too sure about ~/.local/share/dots.git/ though, the basedir spec is for applications and I don't see any benefit in following it for a repo. --Larivact (talk) 21:36, 12 January 2019 (UTC)
From XDG Base Directory Specification the definition is as follows: $XDG_DATA_HOME defines the base directory relative to which user specific data files should be stored. If $XDG_DATA_HOME is either not set or empty, a default equal to $HOME/.local/share should be used.
IMHO git's bare repo for configuration files absolutely qualifies as "user specific data files" (I'd still keep development project's .git folder in the project folder as per default convention, but that is a different use case altogether). There is a difference between the contents of the git repo that you checkout (i.e. configuration files themselves) and the repo itself - which is rarely accessed directly as it has folders with hashes and blobs that are useless to look at for anything but data recovery. In that sense it is no different from any other program's data folder in that directory. Just my 2c. Romstor (talk) 22:22, 12 January 2019 (UTC)