Skip to content

Instantly share code, notes, and snippets.

@tbnorth
Created August 6, 2026 18:55
Show Gist options
  • Select an option

  • Save tbnorth/14af2a2ad306bf1972ecb8a3cac370eb to your computer and use it in GitHub Desktop.

Select an option

Save tbnorth/14af2a2ad306bf1972ecb8a3cac370eb to your computer and use it in GitHub Desktop.
Manage files scattered across your whole file system with one git repo.

Whole file system git coverage

You can use git to manage single files spread across your whole filesystem, things that you wouldn't create individual repos. for, but really want to backup / revert sometimes. This does not interfer with regular git repos. in the same file system.

First, create some bash, or similar, aliases:

alias ggit="git --git-dir=$HOME/global_git --work-tree=/"
alias ggitadd="ggit update-index --add"

Then

git init --bare $HOME/global_git

creates a repo. $HOME/global_git - this is like a .git folder, don't look for files in that folder, the "working tree" where you can see you files is the whole filesystem.

Finally

ggit config --local status.showUntrackedFiles no

Now you can use ggit anywhere as you'd use git normally. In some cases ggit add may not work as expected, so just use ggitadd instead.

Examples:

ggitadd .bashrc
ggitadd /data/path/project/docker-compose.yaml
ggit status
ggit commit -am'update config'

To see a list of all managed files:

ggit ls-tree --full-tree --name-only -r dev

Version control for sensitive data

You can use this approach to manage those important files you should never commit to a repo. - but don't do this unless you're sure you're comfortable with where you sensitive information is visible.

I have used two sets of aliases, ggit for non-sensitive scripts etc. and the same aliases just substituting sgit for ggit (and changing the path to $HOME/sensitive_git or whatever).

You can push the non-sensitive repo. to a remote or otherwise backup the $HOME/global_git folder, and not move the sgit repo. off the machine containing the sensitive data. So the only additional exposure is the presence of the sensitive data in $HOME/sensitive_git as well as it's original file-system location. Anyone who can access $HOME/sensitive_git can probably access the original location too. It's a trade-off, the value of being able to revert changes that broke something against being mindful extra folder.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment