5 ms·

> 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

> 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.

npteljes 2y ago
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.
g4zj 2y ago
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?
- Vinnl 2y ago
  I imagine it includes things like .DS_STORE.
- tomjakubowski 2y ago
  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 2y ago
    Similarly, I globally exclude `*.tmp`. I can pipe logs or anything else to some `example.tmp` and never worry about checking them in.
  - dunham 2y ago
    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.
- MrJohz 2y ago
  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.
jcalvinowens 2y ago
Agreed, I don't want my checkout implicitly ignoring a file somebody else's checkout wouldn't.
- tremon 2y ago
  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.
idle_zealot 2y ago
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 2y ago
  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
zaptheimpaler 2y ago
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.
- dkarl 2y ago
  I always put IDE-specific ignores in a global gitignore since not every project gitignore has an entry for every IDE.
- codetrotter 2y ago
  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.)
  - jedberg 2y ago
    You don't keep your dot files in git? :)
    - codetrotter 2y ago
      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 https://github.com/ctsrc/zshrc
isaacremuant 2y ago
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.
edoceo 2y ago
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.
DEADB17 2y ago
https://git-scm.com/docs/git-check-ignore https://git-scm.com/docs/git-check-ignore is useful to diagnose why a file is ignored

npteljes 2y ago

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.

g4zj 2y ago

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?

Vinnl 2y ago
I imagine it includes things like .DS_STORE.
tomjakubowski 2y ago
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 2y ago
  Similarly, I globally exclude `*.tmp`. I can pipe logs or anything else to some `example.tmp` and never worry about checking them in.
- dunham 2y ago
  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.
MrJohz 2y ago
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.

jcalvinowens 2y ago

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

tremon 2y ago
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.

idle_zealot 2y ago

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 2y ago
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

zaptheimpaler 2y ago

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.

dkarl 2y ago
I always put IDE-specific ignores in a global gitignore since not every project gitignore has an entry for every IDE.
codetrotter 2y ago
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.)
- jedberg 2y ago
  You don't keep your dot files in git? :)
  - codetrotter 2y ago
    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 https://github.com/ctsrc/zshrc

isaacremuant 2y ago

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.

edoceo 2y ago

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.

DEADB17 2y ago

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