Hi everyone!

I am happily using Stow to keep my dotfiles together in one dir and back them up daily using Borg to my external HDD (and that HDD regularly to a 2nd HDD).

I understand that many people use Git to backup their dotfiles by pushing them into a remote repo. For example yesterday DT uploaded a video showing the setup.

I know there are many people who find this setup marvelous and get defensive about it. Perhaps there is something I am missing, can someone convince me about the benefit of using Git for my dotfile backup? Sure, it's handy to do "git pull" or "git clone", but apart from that I can only see the negatives:

1. Privacy - There could be sensitive information in my dotfiles which I don't want to upload - I might not even realize that sensitive info is there and therefore accidentally not use .gitignore (and I don't believe in "private" repos, once it's uploaded I have little control)
2. Security - I know I might be paranoid, but my data could get maliciously changed while sitting in the remote repo (again, how much control do I really have?) - my own HDD seems much safer
3. Lots more work - adding to the staging area, committing and pushing are 3 commands as opposed to a single command with my Borg backup system (which can BTW be automated)
4. This is not exactly Git's weakness, but my Borg setup also does a basic "version control" - I can easily revert my files to how they were a week ago for example

I am curious about your answers. Maybe you'll change my mind?

(BTW, Borg is an excellent backup program which deserves much more fame than it currently has)

In a previous life, I used RCS to keep track of many of the files under /etc on several large departmental clusters I was responsible for. Being able to roll back a change was a real boon. Especially when, following a corporate re-org, those systems started being managed by a team with some members only beginning to learn how to manage clusters. Since all system changes had to be approved, the change control folks like that we "scripted" (I don't mean a shell script, BTW) the changes before executing them before rolling them out and included that in the change requests. Saving the current state of any files that were going to be modified was Step 1. In the unlikely event that a production change went awry in a way not seen in the test environment (close to but not exactly like prod), having that initial state available for restore saved everyone's bacon.

Replace RCS with Git[1] and that practice would be what we'd be doing today if those boxes were still in use.

HTH...

[1] - I suspect, that in lieu of Github, we'd have found a way to run Git locally, use gitolite, etc. to keep the internal auditors happy.

1 members found this post helpful.