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)

Troublesome binary files

Would it be appropriate to add tips for dealing with obnoxious binary files that change often if one intends to keep their dotfiles in git? One such file in particular I'm thinking about is dconf. In dconf's case, man 7 dconf hides a very useful tip I spent way too long searching elsewhere to find:

On startup, dconf consults the DCONF_PROFILE environment variable. If set, dconf will attempt to open the named profile, aborting if that fails. If the environment variable is not set, it will attempt to open the profile named "user" and if that fails, it will fall back to an internal hard-wired configuration. dconf stores its profiles in text files. DCONF_PROFILE can specify a relative path to a file in /etc/dconf/profile/, or an absolute path (such as in a user's home directory).

It's not clear how that helps us, except just above that in the manpage it said:

The binary database format that dconf uses by default is not suitable for use on NFS, where mmap does not work well. To handle this common use case, dconf can be configured to place its binary database in XDG_RUNTIME_DIR (which is guaranteed to be local, but non-persistent) and synchronize it with a plain text keyfile in the users home directory.

To dump the binary dconf database as text, simply run:

$ dconf dump / > ~/.config/dconf/user.txt

I ran this command while logged in only to a VT, just to be safe. Then I created the default user profile system-wide:

# mkdir -p /etc/dconf/profile
# printf '%s\n' 'service-db:keyfile/user' >> /etc/dconf/profile/user

This StackExchange question is the thing I ultimately found that explained what to do. Upon logging in, changes to dconf are saved to the text file and the binary file is completely ignored. Moreover, the text file may be edited in place (it's in .ini format) and GTK/Cinnamon/Gnome apps will pick up changes as soon as you do.

Caveats: Login takes a moment longer even on SSD. The database must be imported at login. It's kept in sync as you go, and I don't think I've noticed any slowdown on a Ryzen 3000 series CPU. RAM usage is probably a bit higher but I didn't test that. The only other consequence is that the file changes. A lot. I use ibus to let me type emoji and the like without a character picker, and every time I type a character I haven't used yet, it seems to be added to a list, editing one line of the file.

The user.txt also has no coherent collation. New entries are simply appended to the block if it exists, and if it doesn't the new block is appended to the end of the file. On the other hand if you decide you will no longer use a program, you can simply remove it from your system and conveniently erase its dconf entries by hand from your user.txt to make them go away. And since you're going to keep this file in git and theoretically add its changes often, you'll have a pretty good idea what to remove.

That leads to the question: Should the dotfiles page have a section for this kind of nonsense? It wouldn't take much to tighten up the above into a more technical documentation format and add it to a section on the main page. But as this is my first contribution to the wiki and I've been running Arch BTW for about fifteen minutes days now, I'm not sure that's appropriate or not. I'm not sure how many other program fill up .config with binary formatted crap—the only other things I can think of offhand are OpenRGB and potentially hexchat, and neither of those things have the binary crud change often enough to worry about it.

How do we handle this then, or do we handle it? May be that I'm the only one irritated enough by this Gnomism to do anything about it?

Knghtbrd (talk) 12:25, 4 September 2024 (UTC)

IMO it's better to have a dedicated subsection in GNOME/Tips and tricks for the details, an we only keep here a link to it with a short explanation like "we need a workaround for GNOME and its binary configuration file, see link for the details on setting it up".

-- Erus Iluvatar (talk) 15:20, 4 September 2024 (UTC)

That'd make sense if it didn't apply to most other DEs that are GTK-based (except XFCE which still uses its own settings database that predates GTK's). Maybe GTK#Configuration or GTK#Troubleshooting make more sense?

Cross-referencing would be easy enough then.

-- Knghtbrd (talk) 09:31, 5 September 2024 (UTC)

Right, dconf is not GNOME-only /o\

GTK#Configuration seems like the most fitting section.

-- Erus Iluvatar (talk) 11:20, 5 September 2024 (UTC)