Talk:Dotfiles

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)

I've independently implemented https://github.com/eli-schwartz/dotfiles.sh in order to do this, maybe helpful? -- Eschwartz (talk) 03:49, 27 January 2019 (UTC)

FWIW, I call the git alias githome. Mehdix (talk) 18:13, 26 May 2021 (UTC)

Move Tools section into List of applications

List of applications might be more suitable to list all the different dotfiles managers than having them listed just here.

Scrumplex (talk)

Windows/PowerShell dotfiles management?

I know this is a place to talk about Arch Linux. But since PowerShell cross platform at this point, and because Arch Linux Wiki is already such a great knowledge base, maybe we can include links to dotfiles management solutions which apply to specifically PowerShell and generally to MS Windows too? Ratijas (talk) 13:24, 26 June 2021 (UTC)

Git approach fails on permissions and ownership

I find Git rather unsuitable to track dotfiles as outlined on the wiki article, because git *does not record permissions* except for the executable bit. I.e., if your setup contains only two files with different permissions, then Git won't be able to reproduce your setup correctly.

Unfortunately, it's not done with simply setting the permissions on the system by hand, after doing a git checkout: If you use branches to track different setups, then switching between branches will reset the permissions of each file that has to be created in the file system. The following experiment demonstrates this:

In an empty directory:

$ git init
$ touch README
$ git add README
$ git commit -minitial
$ git switch -c devel

We're not concerned with the `README` file.

I'll add to the `devel` branch two files with different file modes.

$ for m in 0644 0600; do
    date > "file_${m}"
    chmod "${m}" "file_${m}"
    git add "file_${m}"
  done
$ git commit -m'two files with different modes'

Now switching to `master` (where the files are not present) and returning to `devel`, deletes and recreates these two files in the file system:

$ git switch master; git switch devel
$ ls -l
total 8.2k
-rw------- 1 sk users 32 Feb  5 10:33 file_0600
-rw------- 1 sk users 32 Feb  5 10:33 file_0644
-rw------- 1 sk users  0 Feb  5 10:30 README

Note, that both files have the same mode, which is wrong. The mode you actually see depends on the umask:

$ umask
0077

And by changing the umask, one can change the mode with which the files are recreated:

$ umask 0022
$ git switch master; git switch devel
$ ls -l
total 8.2k
-rw-r--r-- 1 sk users 32 Feb  5 10:34 file_0600
-rw-r--r-- 1 sk users 32 Feb  5 10:34 file_0644
-rw------- 1 sk users  0 Feb  5 10:30 README

The caveat is, that the modes of the generated files depend on the global umask, not on their individual mode when being committed.

IMHO, this makes the proposed approach unfit to track a system's configuration.

Furthermore, file ownership has not been discussed at all.

Stefan2 (talk) 09:56, 5 February 2023 (UTC)

This article about user specific configuration (e.g.: which resides in $HOME). Usually, this directory is only readable by the owner, so permissions are seldom relevant for this. I think that saying that "the proposed approach is unfit" is a bit of a stretch, it's probably very edge cases that care about permission of configuration files. The only files in $HOME where I even care about permissions are SSH keys, and those are not kept in a dotfiles repository anyway. What kind of configuration file needs different permissions for you?

—This unsigned comment is by Hobarrera (talk) 2023-02-08T16:55:09. Please sign your posts with ~~~~!

Sorry for writing so much =(

Yes, the introduction of the article can be read as “refers only to non-system-wide config files in a user's home that start with a dot”, but I'd rather read it as “configuration files, e.g. (but not limited to) the dotfiles you have in your home”.

I prefer the latter, broader interpretation, because in Linux/Unix jargon, “dotfile” refers to hidden files, not necessarily config files, although mostly used that way (not: `.gitkeep`). Also, some config files do not even start with a dot, but may rather end in `rc`, `.cfg`, `.ini`, or may not follow any convention (`Vagrantfile`). They may, but don't have to reside in a hidden directory.

Assuming that the article would clearly target exclusively the user-owned dot files as you seem to imply: Then I'd need a *different* tool to maintain the remaining system configuration, which is capable of tracking mode and ownership. Then why not use that to track user configuration as well? Then why use Git at all?

Hence, I find the narrowing of the applicability to files which match `.*` *and* are owned by a non-root user invalid.

“The only files in $HOME where I even care about permissions are SSH keys, and those are not kept in a dotfiles repository anyway.” — I agree about not maintaining SSH keys in a git repository, but that does not mean that everyone does. Git may very well be used locally only, for history and rollback. In that case, a user may very well add even a secret key (although we probably both doubt the usefulness of this). After all, a secret key may be contained in a backup, so why not in a local git repository?

“[…] so permissions are seldom relevant for this […]”, which contrasts nicely with my second sentence above: “if your setup contains only two files with different permissions, then Git won't be able to reproduce your setup correctly” — so the error condition may appear seldom. But that's not a reason to assume it won't happen at all: Just because one is not affected by a bug (well, it's not really a bug, is it) does not mean it's not there. If the effect (rather than bug) raises its ugly head, then likely because “switching between branches will reset the permissions” (me), which may likely go unnoticed.

Even as non-privileged user, I do have a couple of files that are write protected as a reminder to myself to think twice before changing them. I'd rather keep them that way, and I'd certainly not expect my configuration-tracking-tool to mess with them.

So yes, I agree, for the use-case that all tracked files have exactly the same mode and ownership, and the user is aware of this as a necessity, and this never changes in the future, then git may be appropriate. But the user will not be able to extend this approach to system configuration, due to lack of tracking ownership and permissions. Which makes Git a niche solution (for this particular task. I do use and like Git a lot.).

Stefan2 (talk) 18:45, 12 February 2023 (UTC)

What you are looking for goes under configuration management category.[1]

Arash (talk) 12:25, 18 January 2024 (UTC)