1

I keep my dotfiles in a private git repo on bitbucket and this works great for the majority of my files (.vimrc, .tmux.conf etc) then I just set up symlinks from my home directory to my cloned gitrepo of dotfiles and everything works great.

My problem is that I also use the prezto framework to manage zsh plugins. Prezto does something similar in that it stores all the .zprezto* config files in its own directory and symlinks to them from home. One of those files is the .zshrc which it stores in its own directory.

It looks like this:

.zlogin -> /home/jordan/.zprezto/runcoms/zlogin
.zlogout -> /home/jordan/.zprezto/runcoms/zlogout
.zpreztorc -> /home/jordan/.zprezto/runcoms/zpreztorc
.zprofile -> /home/jordan/.zprezto/runcoms/zprofile
.zshenv -> /home/jordan/.zprezto/runcoms/zshenv
.zshrc -> /home/jordan/.zprezto/runcoms/zshrc

How am I able to track my .zshrc file in my own git dotfiles directory without breaking prezto.

  • 1
    Would git submodules (git-scm.com/docs/git-submodule) suit your needs? It's used to have a repository inside another one, the inner repository being a dependency of the main one. – lgeorget Sep 13 '16 at 12:31
1

You can use a hardlink in this instance, presuming you are not crossing file system boundaries. In case you are unaware, a hardlink is much like a symlink, but from a process perspective the file is a normal file. This includes git, which will properly work with them and archive them as normal files with content and not symlinks.

Because git doesn't track such links, however, if the file is deleted and recreated by the repo for some reason, it will break the hardlink, so that is something to keep an eye on when using git.

To be clear, I mean you create a hardlink from Pretzo's primary stored instance to a version in the directory where you keep the git backed dot files. Pretzo will see it as a regular file, so will git, and note hardlinked files can be symlinked, so their deployment that way is fine.

Like a symlink, it means a change to one version changes the other, since technically they are the same data on storage (with multiple associated file nodes). Beware hardlinks are harder to notice than symlinks with many tools since they are usually not explicitly indicated (I don't know how this applies to various GUI filebrowsers; I think generally they will just be regular files). However, you can spot them based on the number of links shown with ls -l (second column), stat, etc. Normal files that aren't hardlinked have a link count of 1 (and directories are not normal files, so their link count varies). Unfortunately, unlike with symlinks, there is no simple way to find the other nodes, just the link count indicating they exist. So do not start doing this willy-nilly, do it systematically as in this context so you know why and where the other nodes are.

Caveat

This does mean there is the potential, if you are deploying this way on multiple systems (your post is ambiguous on this point), to run into issues if Prezto is prone to making changes to these files of its own accord. That will lead to situations where a file has updates pending via a pull but these conflict with local changes made by Pretzo, and merging at that point is probably bad, so you would have to decide what to do (note you can delete a hardlink and it does not delete all the other copies).

However, if these are all configuration files that you know Pretzo only reads and does not screw with (which is sort of implicit in the idea of git tracking them across systems), then you are okay. Also, if you are just using this repo as a backup of one particular system it doesn't matter, the aforementioned scenario can't happen.

The only other issue is that you cannot use hardlinks across filesystem boundaries. I.e., if your master git backed store is on a mounted filesystem separate from Pretzo's own store, you are out of luck with this method.

  • Exactly what I needed. I had thought about hard-linking the files previously but I was unsure as to how git would handle that. Thanks! – Jordan Sep 13 '16 at 13:32
  • @Jérôme I think that issue is more to do with links internal to the repo when it is cloned, pushed and pulled. E.g., if you have two files inside the repo that are hardlinked together, git will track them as two separate files. But it sort of, probably, may not matter if it is one file inside the repo hardlinked to a copy outside the repo. But it is something to be aware, I'll add a note about this -- thx. – goldilocks Mar 25 '17 at 15:36
  • 1
    I didn't try it myself but the link says it seems to work "…until you try to have Git update the file. Perhaps you made a change somewhere else and now want to git pull, or perhaps you made a change locally that you decided you didn’t want and so you use git checkout .vimrc in your repo to change it back to your committed version. At this point you discover that while it seems to change the file in your repo, it doesn’t update the file in your home directory – the hardlink has been broken." – Jérôme Mar 26 '17 at 8:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.