[videlov]

> excludesfile = ~/.gitignore

It has happened to me in the past to wonder why certain files/folders are ignored by git, only to realise that I had a global git ignore for the particular pattern.

Not sure l’d recommend this as a good default, but perhaps others have better memory than I do.

[zaptheimpaler]

My gitignore is just a pile of things I _always_ want to ignore:

     # OS
    .DS_Store

     # Editors
    .vscode-server/
    .idea/

     # Javascript
     .npm/
     node_modules/

     ...more stuff per language

I find it really nice to just keep all that in one place and not have to configure it per project. There's nothing too broad or situational in there that might get in the way - those kinds of things can go into the project specific .gitignores.

There's also `git status --ignored` to check if you're missing anything.

[codetrotter]

My reason for having each and every common ignore in each individual repo is that on the off chance that someone else wants to contribute to any of my projects, those files are already ignored for those people too.

And also, sometimes I work from different machines and I don’t really want to have yet another dotfile to sync between all my current and future machines.

(Yes, I know dotfile managers exist, but I literally only care about syncing my zsh config files and one or two other dotfiles mainly so I do that with my own little shell script and basically don’t care about syncing other dotfiles.)

[_blk]

Generally agree with you but I'm not going to clutter my project's .gitignore with stuff that's in the responsibility of the user to keep in their own ignore list like .DS_Store. E.g. Each js project gets a /.npm /node_modules, each py proj a .pyc etc... Editor is generally one per project which checked in config (.vscode) and if you want to use vim, have your own rules for ~ which you likely have anyway. Also, both are not exclusive: .env can be checked in and in .gitignore

[jedberg]

You don't keep your dot files in git? :)

[codetrotter]

Yes, they are in a git repo :D

I just mean, it’s intentionally not a fancy setup with all kinds of things.

Just the most essential stuff and some symlinks. For the few dotfiles I really care about.

In an ideal world, I wouldn’t need any dotfiles at all. And my home directories would only contain files that I myself put there. Like my photos, my music, and code that I write. Those kinds of things.

That’s the main reason I don’t like managing all of my dotfiles. Because I don’t really want them in the first place. The only thing I want less in my home dirs but which I also have to live with is all of the other garbage that programs I use put there on their own. Like caches and different weird files that the programs decided should be there.

https://github.com/ctsrc/zshrc

[dkarl]

I always put IDE-specific ignores in a global gitignore since not every project gitignore has an entry for every IDE.

[idle_zealot]

It makes sense to have global defaults specific to your machine if and only if your workflow (editor, personal tooling) creates files that you don't want as a part of any project. Things like vim or emacs temp files, macOS's DS Store files, etc. This doesn't apply if your team uses standardized editor configs.

[kyleee]

Tangentially you can set vims temp/swap files to something like ~/.vim/tmp/ so they don’t clutter repo directories. At least that’s my pref for this annoyance/clutter

[edoceo]

I have to put a complete one in every project. I work with a lot of junior devs. On many occasions they're committing too much - cause they a) don't have good global config and b) are not selective about git add. A teaching opportunity but annoying to clean up.

Just a view from the other end of the spectrum.

[g4zj]

This option in general seems odd to me. Wouldn't all contributors to the project need to coordinate their exclusions manually this way? Am I missing something?

[MrJohz]

You would normally use both this and a project-specific gitignore.

The project-specific file is for stuff that should be shared amongst all users of a particular project. So for a Node project you might have `node_modules` in there, for a Python project you might have `.venv` and `*.pyc`. If your project uses env files, you might have a line like `.env` in there for that.

Meanwhile, the global gitignore is for stuff that's specific to your system. If you're on MacOS, you might have an entire for `.DS_Store`, or if you use Vim a lot you might have an entry for `*~` files (i.e. vim backup files). This is stuff that's specific to you.

Git can then combine the project-specific ignores (located in the project respiratory) and your user-specific ignores (located in your global gitignore file), and ignores anything that matches either case.

[Vinnl]

I imagine it includes things like .DS_STORE.

[tomjakubowski]

It's useful for bespoke developer settings. I like to keep a scratch folder in virtually every repo I work on, so I have `/tomscratch` in my global excludes file. Adding this to .gitignore in every repo I work on would just be noise for everyone else.

[jjayj]

Similarly, I globally exclude `*.tmp`. I can pipe logs or anything else to some `example.tmp` and never worry about checking them in.

[dunham]

I've been putting a .gitignore file containing a single * inside my scratch directories. But ~/.gitignore sounds like a good idea for local things that I do in every repository.

[jcalvinowens]

Agreed, I don't want my checkout implicitly ignoring a file somebody else's checkout wouldn't.

[tremon]

Probably not what you meant, but git checkout is not affected by .gitignore anyway. If a file is already in the repository, git will keep tracking it.

[isaacremuant]

I disagree. If it's minimalistic and focused on your commonalities across projects in a computer, such as VScode stuff which shouldn't be committed to a general repo, I think it's the right and unobtrusive choice.

[DEADB17]

https://git-scm.com/docs/git-check-ignore is useful to diagnose why a file is ignored

[npteljes]

I agree with you. In fact, I think it's better to free up "configuration" memory, and use it to store "best practice" or "process" in general. I find that convention over configuration works out better on a long run, and when switching between projects - either the developer themselves, or when parts of the team leave and others join.