On 2022-10-12 at 16:35:51, Thorsten Schöning wrote: > Hi everyone, > > I'm using SVN to maintain lots of different host specific configs like > crontab files, web server configs and the directory /etc/sysstat. The > current approach is to simply have some directory structure in trunk > named by topics like /trunk/Mail/Postfix for some reference host, if > any makes sense at all. That config is then copied to e.g. > /tags/Mail/Postfix/some.other.host and Postfix for that host > maintained in that writable tag. > > GIT doesn't have writable tags, which might be worked around using > branches or one repo per host or stuff. The more important difference > is that SVN can have a working copy for each and every maintained > directory. So one can really make /etc/postfix or /etc/sysstat a > wroking copy and maintained that only, without additionally necessary > subdirs and without having .svn in /etc or alike. AFAIK that is not > possible in GIT, even with sparse checkouts one needs a subdir of > some kind, which is pretty incomplatible with many system wide > configs. Unless one wants to put .git into / or /etc or alike, which > is what I would loike to avoid. > > Any useful suggestions for workarounds? There are a couple approaches you can take. One is to keep the repository elsewhere and simply copy files into place. This is how I and many people manage our respective dotfiles with Git. Another option is to use some sort of automatic system for managing those config files, such as Puppet, Chef, or Ansible, and keep those files in a repository suitable for that system. This is how I manage configuration for my servers and how we do it at work. Finally, you can also keep the Git directory separate from the working tree. For example, if you're in /etc and your repository directory is /srv/checkouts/etc-git, you can run one of the following: $ GIT_WORK_TREE=/etc GIT_DIR=/srv/checkouts/etc-git git status $ git --work-tree=/etc --git-dir=/srv/checkouts/etc-git status (Note that you must set both environment variables or both options, not just one.) Of course, this is a little unwieldy, so a shell script may be helpful. You'll also want an appropriate .gitignore file. > I can only think of two things: Putting the GIT clone somewhere and > link directories into that. Which won't work very well for directories > for which I only want to maintain some and not all files and seems > like a lot of work, might break package management etc. Git does not preserve hard links and this won't work in general. Since Git also does not preserve permissions other than the executable bit, so you almost certainly will not want to use symlinks, either, since that means the destination directories may change ownership and permissions when you run git checkout. -- brian m. carlson (he/him or they/them) Toronto, Ontario, CA
Attachment:
signature.asc
Description: PGP signature
