https://www.atlassian.com/git/tutorials/dotfiles
tl;dr: it puts the .git directory aside and lets you use it to store any files on your filesystem.
All the usual commands work, except you use something like `config` or `dofiles` instead of `git`:
$ config add ~/.config
$ config commit -m initial\ commit
I didn't know about `git config --local status.showUntrackedFiles no` so I just put '/*' into .home.git/info/exclude, and then of course tracked that in itself by adding '!/.home.git/info/exclude' in there too.
It's been amazingly useful when acquiring a new laptop, or wanting to quickly set up a comfortable environment on remote machines.
Interestingly, I got it from a Stackoverflow answer (https://stackoverflow.com/a/27336975/8002) and not the atlassian tutorial you listed.
$ git remote add foobar address:path/relative/to/home/dir
$ git push foobar
Is this a problem if you gitignore * (whitelisting)?
What about storing such files in a password manager/database?
Nothing can really protect someone from this level of insanity.
In a similar vein, I also have a git repo containing my todo list, journal, etc. and review and commit the changes once a week. Very helpful for catching accidental deletions/modifications. I have never been tempted to push these repos.
Real world example:
- Let's say I want to version control ~/.ssh/config and ~/.ssh/authorized_keys
- I move these two files to ~/.dotfiles/ssh
- ~/.dotfiles is version controlled, so I push the new files to gitlab. I'm only pushing two harmless files: my ssh configs, and authorized keys. Git, stow, and ~/.dotfiles don't see anything else.
- After pushing, I run "stow ssh" inside ~/.dotfiles. This symlinks these two files to ~/.ssh
I don't worry about pushing anything sensitive, because it's basically impossible for me to accidentally move something to ~/.dotfiles and then run 'git push.'
git-remote-gcrypt: https://github.com/spwhitton/git-remote-gcrypt
git-crypt: https://github.com/AGWA/git-crypt
git-secret: https://github.com/sobolevn/git-secret
However, most people who self-host their Git repository are fine with just transport-level encryption (TLS).
As far as fossil is concerned, once you close the repo, it's out of site of mind. I still use git for most everything else. Only my dot files and my personal obsidian vaults are backed up to fossil.
> I was using git, however I like that fossil allows you to put the repository where ever you want on the file system. I don't have to worry about alias's, using .gitignore, or setting it it up where it doesn't show untracked files.
Git also lets you put the repository wherever you want on the filesystem, via worktrees or via the `--separate` link. And I fail to see the relationship with aliases or ignore files (the last item I guess you're talking about fossil not showing untracked files by default?)
Fossil doesn't show much unless you perform a open or a checkout against the repo file. Generally, it only shows the location of the config database ($HOME or $XDG) exmaples below. The added benefit is that you can do this open/checkout anywhere on the system. For instance, if I'm making changes in my /etc, I can commit a file from there without having to move the file. Another nice feature is they have an unversioned [1] mechanism as well, which allows you to commit files that you want to save but don't care about the history.
Ran from my $HOME
-------------------------
$ fossil info
config-db: /home/$USERNAME/.config/fossil.db
fossil: /home/$USERNAME/.local/bin/fossil
version: 2.19 [1e131febd3] 2022-07-21 16:10:55 UTC
$ fossil status
current directory is not within an open checkout
--------------------------
Used several times to back up some critical configurations (3rd/4th paranoia backup right before maintenance) on a few servers because the commit/open from anywhere. It doesn't pollute the file system as it's a single file.
With the untracked files: It's a little different. The git way you usually use do the dot file backup is with an alias `--untracked-files=no` so you don't see them unless you override it. At least most of the examples I followed the processes I've experimented with over the years recommended.
With fossil you see them when you consciously issue a fossil open in order to do a commit. I'd rather see the untracked files, when I'm ready to commit then to not see them at all and miss something. Out of site. out of mind is something I personally struggle with.
[1] https://fossil-scm.org/home/help/uv
* Edited for formatting.
Otherwise, you can always use chisel [0]
It's handy but sometimes a bit of manual preparation must be done on a new clean machine. For example if you want to stow only some files under ~/.config/program/ and not the whole program/ directory, you must first run an mkdir and then run stow to put the appropriate symlinks in place.
I don't blame you for not knowing about this flag. Here's its description in the manpage:
> Disable folding of newly stowed directories when stowing, and refolding of newly foldable directories when unstowing.
This is confusing because it's a circular definition. It doesn't explain what "folding" means. It should just read, "prevents creation of symlinked directories" or something.
For example, on a machine where ~/.config/autostart/ doesn't still exist, I do not want that either ~/.config or ~/.config/autostart are created as symlinks to my stowed package; otherwise any newly installed file, from unrelated apps, would end up in my package! I just want this path to exist as a proper dir, and only contain whatever symlinks are needed from stow. Thus an `mkdir -p` is still needed before running stow.
On the other hand, I do want that ~/.config/wireshark/ is a symlink to the stow repository. So no mkdir in this case.
Regardless, having a script that adds extra per-package pre-process/post-process logic before/after running stow is still needed, anyway.
I think i say this everytime a dotfiles manager comes up.
Is there a reason to avoid symlinks? I've been using this setup for a few years now, (using an artisanal, home-rolled script before I discovered stow) and it's worked superbly.
[0]: https://monkeyfacts.io/git-whitelist-directory-subfiles/
And I agree, symlinks seem like a smell.
What’s it called when people do that?
Using GNU Stow to manage your dotfiles (2012) - https://news.ycombinator.com/item?id=25549462 - Dec 2020 (113 comments)
Using GNU Stow to manage dotfiles (2013) - https://news.ycombinator.com/item?id=15196141 - Sept 2017 (24 comments)
Using GNU Stow to manage your dotfiles - https://news.ycombinator.com/item?id=8487840 - Oct 2014 (68 comments)
Using GNU Stow to manage your dotfiles - https://news.ycombinator.com/item?id=6331485 - Sept 2013 (69 comments)
I keep my dotfiles in a private git repo, and in that repo is a shell script that creates symlinks (or creates folders with symlinks inside).
Paths are hard-coded in the shell script, but that actually reduces my cognitive load.
https://gist.github.com/clktmr/7343895cc0dcc5a80a6c3d39d22ca...
This will also backup and restore any files it might override.
Infrequently, even on binary files (smirk).
There, I have said it, and taken the load off my conscience...
The last time I dug into this, `homeshick` was had more features and fit my needs better than `stow`.
Alternatively, check out YADM[3], "Yet Another Dotfile Manager", which I'm probably switching to once I get some time.
[1] https://github.com/technicalpickles/homesick
[2] https://github.com/andsens/homeshick
[3] https://yadm.io/
obligatory vanity link: http://noriceno.life
However, typically they don't mention that more recent versions of Stow actually have specific functionality for dotfiles, which is support for the `dot-` prefix.
Check the man page for your version of stow. If the string "dot-" doesn't appear anywhere, you have an old version of stow.
Also interesting to me was the fact that the `make` manual has information on how `stow` is actually one of the recommended workflows in makefiles (in the context of setting a DESTDIR); but I've never seen anyone actually do that in practice.
a magic word used in the Infocom/Sorcerer games to record an incantation in your spell book.