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.
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.
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.