Also of use is .git/info/exclude which is basically a per-(local)repo .gitignore that you can’t track/commit.
You don’t need to do git config --global core.excludesfile. This file has a default path (.config/git/ignore on many systems, but see man gitignore). Just use that file.
git config --global core.excludesfile
As a vim user, I tend to add the following lines to .git/info/exclude or my global gitignore:
so as to not litter per-project .gitignore files with my editor’s stuff for other collaborators.
As an alternative, you can store these files in ~/.cache/vim instead of the current directory; I use this in my vimrc:
" Set/create directory to keep backup, swap, undo files.
set backupdir=$HOME/.cache/vim/backup | call mkdir(&backupdir, 'p', 0700)
set directory=$HOME/.cache/vim/swap | call mkdir(&directory, 'p', 0700)
set viewdir=$HOME/.cache/vim/view | call mkdir(&viewdir, 'p', 0700)
set undodir=$HOME/.cache/vim/undo | call mkdir(&undodir, 'p', 0700)
if &viminfofile isnot# 'NONE' |
if isdirectory($HOME . '/.vim/tmp') == 0
:silent !mkdir -p ~/.vim/tmp >/dev/null 2>&1
but I kinda like yours more.
It may be better to use /TODO.md and /playground, so it’s more specific. Otherwise, if a project (possible one you contribute to) has a directory or file with that name, it’ll be accidentally ignored too. I once ran in to problems where a project had prog-binary in the .gitignore, but then that also ignored etc/sv/prog-binary. Took me quite a while to figure out why the service wasn’t started in the Docker container 😅 Since then I’ve always tried to be as specific as possible with gitignore patterns.
I use .git/todo for this btw.
This is interesting (and @arp242 wrote about storing stuff in the .git folder), but in my mental model when git status runs clear the project is techically purgeable. I wonder: have you ever accidentally deleted something because you forgot it was there?
I think that’s true, but only for the current branch, right? If you have unpushed changes in another branch, then I don’t think git status will tell you about that. Same thing with stashes, .git/config and so on. There’s probably more.
Ah yes, this reminds me that I never got why the default hook mechanism is having (untracked) scripts in .git/hooks, especially if you write anything non-trivial in any of these files… maybe my ideas on the long-livedness of a local repo is a bit at odds with Git’s design. I view the remote as the source of truth with everything that’s not tracked as disposable or regenerable.
Yeah if hooks start getting complex, then I put them in the repo somewhere and symlink them into .git/hooks. Not a great solution, but it’s low tech.