9 ms·

Additionally git supports a global git ignore. $ git config --global core.excludesfile ~/.gitignore Then you can put all the standard things you want to i

by Dobbs 4y ago

Additionally git supports a global git ignore. $ git config --global core.excludesfile ~/.gitignore Then you can put all the standard things you want to ignore into it: $ cat ~/.gitignore .DS_Store ./drafts/ *.swp And it will apply to all git commands on your computer.

sph 4y ago
I also got in my ~/.gitignore: .envrc # direnv, where I store my local project configuration .vscode and when I remember to use them: *.gitlocal *.gitlocal* To store files and directories I don't ever want to push, mostly for scratch files and logs
- AlfeG 4y ago
  Why to ignore .vscode? We collect there workspace wide team settings.
  - sph 4y ago
    I don't think editor-related settings should be committed, unless it's a company repo and everybody is forced to use the same editor. Otherwise all projects would be littered with .vscode, .atom, .sublime, .dir-locals.el, etc. which isn't great. Anyway, stuff in .gitignore can still be added to the index if you so wish.
    - downsidesabound 4y ago
      If almost everyone uses some editor, then it’s not really “littered”. We do the same and it’s nice for new teammates to quickly get set up. If they are one of the few folks that want to use some other editor, who cares? Files are free.
      - pjerem 4y ago
        When almost everyone uses the same editor, it doesn't mean that everyone wants to have the same configuration. Editors and IDEs are crafting tools. Crafting tools are meant to be mastered by workers (here: developers), not to enforce some team/company policy. There are tools that already exists to enforce team policies like formatters, linters and so on. These tools generally integrate well with your editor of choice and can also be integrated on your CI pipelines.
        ascagnel_ 4y ago
        I feel like a better option than committing is to have developers submit sample configurations and make them available in a subfolder or a dedicated configuration repo -- this way, newcomers to the team can pull in existing configurations and tweak them, rather than having to start from zero.
      - sph 4y ago
        I said it makes sense iff everyone uses the same editor and the same settings. But many times this is not the case. What do you need to share btw? There's editorconfig, prettier, git hooks, etc. for style. direnv for configuration (I usually commit a .envrc.example file). I can't think of anything else.
        roykanesmith37 4y ago
        At my last job we had a mono-repo with the .idea directory (for IntelliJ) commited. For Java projects IntelliJ needs to sometimes be directed to understand what folders are “resources” to allow better autocompletion and highlighting. For example specifying custom java faces components directory that will be used once the application is packaged into a war file, so IntelliJ knows they are accessible from JSP html files, and will autocomplete and show you what attributes you can modify on the component.
        shagie 4y ago
        I had a dev check in their .idea directory and all the files for a project. This resulted in them checking in the file that had windows and cursor positions checked in too. Each time you went to switch to a different branch, you got the workspace configuration of the last person to commit that file. Another spot of problems was the plugin specific files (that inevitably also got checked in). When someone checked them in again and you hadn't updated this particular plugin, the newer file format caused it to crash. Not a problem for the dev who checked it in, but a problem for everyone else. I am a strong proponent now of not checking in files that are IDE specific unless the developers are all completely aware of what files do what and the associated churn that a file may have through normal use. Having maven and editorconfig instruct IntelliJ on how to make a workspace consistent results in less config file churn and avoids people accidentally checking in the compiler settings on their computer, database configurations (with passwords), run configurations (with passwords) and similar. Checking in IDE files can be done, just that the developers all need to be diligent in checking what they check in. I've rarely been in an environment where that is the case for everyone.
    - abdouls 4y ago
      I've seen a few big repositories upload their .vscode (pretty sure at least one of the Microsoft repos on Github had this). I have a few team who does commit their .vscode folder, they use it to set up their environment the same way (usually when a project differs from another).
    - bloopernova 4y ago
      What about .editorconfig?
      - sph 4y ago
        That's perfectly fine, mandatory even if more than one person touches the code.
    - blueberrychpstx 4y ago
      you didn't list .idea :'(
  - junon 4y ago
    Please never commit IDE config. It doesn't belong in repositories. It is not a source file of your project.
    - dougdonohoe 4y ago
      Actually, this can be quite useful (at least with IntelliJ) to share common run configurations (e.g., run all tests, start this server with these settings) and other settings. IntelliJ recommends not checking in a few types of files that are specific to the individual: https://intellij-support.jetbrains.com/hc/en-us/articles/206544839-How-to-manage-projects-under-Version-Control-Systems https://intellij-support.jetbrains.com/hc/en-us/articles/206...
      - sph 4y ago
        Makefile or adding those scripts to package.json is a much better idea than vscode's own task configuration file which might not work if someone uses another editor.
        fomine3 4y ago
        Why not both?
    - jameshart 4y ago
      'never' is a strong word. A .vscode/extensions.json file just specifies extension 'recommendations', and I find, really accelerates developers becoming productive in a project. If I want to encourage small, one-off contributions, I want to support a user workflow that's as close as possible to: git clone <project> git switch -t <branch> code <project> npm ci | dotnet restore | terraform init | go get | <whatever> <change and test> git add <changes> git commit git push With the right set of extension recommendations and default code settings, a VS code user can automatically be prompted to get the right test executors, linters, prettifiers, and so on so that they get instant feedback on their changes. It doesn't even matter if many users who work on the codebase day to day actually use emacs or a highly customized IntelliJ setup or whatever - the vscode settings specifically enable the driveby coder to get a working environment fast, and that helps enable the power users to not be bothered by feature requests that could be pull requests.
  - dharmab 4y ago
    Most teams I worked on did not standardize the team's OS or editor. The "canonical" build was a CI server and the development environment was available as a VM or container.
  - rubyist5eva 4y ago
    For the love of God no. I had someone commit theirs and it override my preferred setup and even changed my gd font. You're basically telling your teammates: i am forcing you to work my way so shove it.
- EmileSonneveld 4y ago
  I do the same with with *gitignored*. Handy for output files of tests, and log files. For example: "log_gitignored.txt" or "mesh_transformed_gitignored.stl". I add it to the repository settings, so all collogues have the same behavior.
p1necone 4y ago
This seems like it could potentially be a source of confusion - different devs on the same project would see different ignore behavior.
- rjmunro 4y ago
  Not really, because they only see differences they have caused themselves, so they know about it.
  - xcambar 4y ago
    And so they forget about it.
- izietto 4y ago
  It is as soon as you forget about that-but, speaking of myself, it is not because I'm aware of the fact that I'm using it
- diarrhea 4y ago
  As far as I can see, this only comes into play when newly adding files to be tracked. If you created a 'source.file', but your global gitignore ignores all '.file' files, then you'd notice immediately. You wouldn't commit and push because you were unable to add the file in the first place. If another developer has added a 'source.file' and you pulled it in, your global gitignore would not be triggered, since the file is already tracked in the repo.
  - CorrectHorseBat 4y ago
    It would also come into play of you add code that generates files which should be ignored, but you don't realize the gitignore has to be updated because it's ignored in your own global gitignore.
    - diarrhea 4y ago
      Very good observation. That's a reason I'm itching to try out an approach akin to this (in a future project): https://jasonstitt.com/gitignore-whitelisting-patterns https://jasonstitt.com/gitignore-whitelisting-patterns
vbezhenar 4y ago
Standard path is ~/.config/git/ignore
- toastal 4y ago
  You mean $XDG_CONFIG_HOME/git/ignore
  - lillecarl 4y ago
    "For writing options: write to global ~/.gitconfig file rather than the repository .git/config, write to $XDG_CONFIG_HOME/git/config file if this file exists and the ~/.gitconfig file doesn’t." Everyone aren't using all the freedesktop conventions, so no.
    - everybodyknows 4y ago
      To supply context: the above quote is from the man page, therefore authoritative. $ man git-config It is however densely conditional wording -- could be simplified.
  - vbezhenar 4y ago
    I don't think that XDG_CONFIG_HOME is a thing with Windows or macOS.
alexpls 4y ago
The global gitignore is super useful! I add a “.x” entry to it so that I can create scripts, drafts, etc in a “.x” folder in any of my projects. Wrote more details about how I do this here: https://alexplescan.com/posts/2022/04/17/the-x-files/ https://alexplescan.com/posts/2022/04/17/the-x-files/
- sdoering 4y ago
  You had me - before clicking - at the url-slug "the-x-files". Loved the content and learned something useful. Thanks for pointing it out. Will be another little tool in my belt.
- wonder_er 4y ago
  just set this up on my machine! Thank you so much! I'd just been bumping into this problem, but hadn't conceptualized such an elegant solution, so kept fumbling around, adding/moving things, futzing around with git way more than I wanted to. Thank you!
gertlex 4y ago
I've got a slightly different version of that last rule in mine: *.sw? Since I'm messy enough to sometimes end up with multiple of them for a few files. (Also, not messing with flash files in git, or in general...) But have since moved my vim swap files to ~/.vim/swap with `set directory=~/.vim/swap,.` in .vimrc.
- fomine3 4y ago
  ignoring .swf is a bonus :P
chrisfinazzo 4y ago
Hard agree. Even though I tend to work on only a couple of different kinds of things - at least for now - the global ignore file is a godsend. So good.
tehbeard 4y ago
I heavily advise AGAINST using this for anything apart from OS level file spam (.DS_Store etc). We spent a good part of a day rebuilding a repo after a junior dev. left, when we found out they'd misused global gitignore and hadn't commited several important files due to an ignore they had set for a seperate project. Lessons learnt. Ensure new devs don't use it, and code review on another machine than theirs...
- sitzkrieg 4y ago
  how did that project ever build on ci :)
  - 89vision 4y ago
    but it worked on my machine
    - abustamam 4y ago
      Ship your machine as CI, problem solved /s
      - rubyist5eva 4y ago
        docker wants to know your location
  - xyst 4y ago
    hint: there was no CI
    - superjan 4y ago
      I heavily advise AGAINST not using CI. If properly applied it solves .gitignore mistakes and many more, made by those infamous junior devs. On second thought, not just juniors. Oh well.
  - TheSoftwareGuy 4y ago
mikl 4y ago
Or simply put the file at the default location for core.excludefile, which is ~/.config/git/ignore on Unixy platforms.

by Dobbs 4y ago

sph 4y ago

I also got in my ~/.gitignore: .envrc # direnv, where I store my local project configuration .vscode and when I remember to use them: *.gitlocal *.gitlocal* To store files and directories I don't ever want to push, mostly for scratch files and logs

AlfeG 4y ago
Why to ignore .vscode? We collect there workspace wide team settings.
- sph 4y ago
  I don't think editor-related settings should be committed, unless it's a company repo and everybody is forced to use the same editor. Otherwise all projects would be littered with .vscode, .atom, .sublime, .dir-locals.el, etc. which isn't great. Anyway, stuff in .gitignore can still be added to the index if you so wish.
  - downsidesabound 4y ago
    If almost everyone uses some editor, then it’s not really “littered”. We do the same and it’s nice for new teammates to quickly get set up. If they are one of the few folks that want to use some other editor, who cares? Files are free.
    - pjerem 4y ago
      When almost everyone uses the same editor, it doesn't mean that everyone wants to have the same configuration. Editors and IDEs are crafting tools. Crafting tools are meant to be mastered by workers (here: developers), not to enforce some team/company policy. There are tools that already exists to enforce team policies like formatters, linters and so on. These tools generally integrate well with your editor of choice and can also be integrated on your CI pipelines.
      - ascagnel_ 4y ago
        I feel like a better option than committing is to have developers submit sample configurations and make them available in a subfolder or a dedicated configuration repo -- this way, newcomers to the team can pull in existing configurations and tweak them, rather than having to start from zero.
    - sph 4y ago
      I said it makes sense iff everyone uses the same editor and the same settings. But many times this is not the case. What do you need to share btw? There's editorconfig, prettier, git hooks, etc. for style. direnv for configuration (I usually commit a .envrc.example file). I can't think of anything else.
      - roykanesmith37 4y ago
        At my last job we had a mono-repo with the .idea directory (for IntelliJ) commited. For Java projects IntelliJ needs to sometimes be directed to understand what folders are “resources” to allow better autocompletion and highlighting. For example specifying custom java faces components directory that will be used once the application is packaged into a war file, so IntelliJ knows they are accessible from JSP html files, and will autocomplete and show you what attributes you can modify on the component.
        shagie 4y ago
        I had a dev check in their .idea directory and all the files for a project. This resulted in them checking in the file that had windows and cursor positions checked in too. Each time you went to switch to a different branch, you got the workspace configuration of the last person to commit that file. Another spot of problems was the plugin specific files (that inevitably also got checked in). When someone checked them in again and you hadn't updated this particular plugin, the newer file format caused it to crash. Not a problem for the dev who checked it in, but a problem for everyone else. I am a strong proponent now of not checking in files that are IDE specific unless the developers are all completely aware of what files do what and the associated churn that a file may have through normal use. Having maven and editorconfig instruct IntelliJ on how to make a workspace consistent results in less config file churn and avoids people accidentally checking in the compiler settings on their computer, database configurations (with passwords), run configurations (with passwords) and similar. Checking in IDE files can be done, just that the developers all need to be diligent in checking what they check in. I've rarely been in an environment where that is the case for everyone.
  - abdouls 4y ago
    I've seen a few big repositories upload their .vscode (pretty sure at least one of the Microsoft repos on Github had this). I have a few team who does commit their .vscode folder, they use it to set up their environment the same way (usually when a project differs from another).
  - bloopernova 4y ago
    What about .editorconfig?
    - sph 4y ago
      That's perfectly fine, mandatory even if more than one person touches the code.
  - blueberrychpstx 4y ago
    you didn't list .idea :'(
- junon 4y ago
  Please never commit IDE config. It doesn't belong in repositories. It is not a source file of your project.
  - dougdonohoe 4y ago
    Actually, this can be quite useful (at least with IntelliJ) to share common run configurations (e.g., run all tests, start this server with these settings) and other settings. IntelliJ recommends not checking in a few types of files that are specific to the individual: https://intellij-support.jetbrains.com/hc/en-us/articles/206544839-How-to-manage-projects-under-Version-Control-Systems https://intellij-support.jetbrains.com/hc/en-us/articles/206...
    - sph 4y ago
      Makefile or adding those scripts to package.json is a much better idea than vscode's own task configuration file which might not work if someone uses another editor.
      - fomine3 4y ago
        Why not both?
  - jameshart 4y ago
    'never' is a strong word. A .vscode/extensions.json file just specifies extension 'recommendations', and I find, really accelerates developers becoming productive in a project. If I want to encourage small, one-off contributions, I want to support a user workflow that's as close as possible to: git clone <project> git switch -t <branch> code <project> npm ci | dotnet restore | terraform init | go get | <whatever> <change and test> git add <changes> git commit git push With the right set of extension recommendations and default code settings, a VS code user can automatically be prompted to get the right test executors, linters, prettifiers, and so on so that they get instant feedback on their changes. It doesn't even matter if many users who work on the codebase day to day actually use emacs or a highly customized IntelliJ setup or whatever - the vscode settings specifically enable the driveby coder to get a working environment fast, and that helps enable the power users to not be bothered by feature requests that could be pull requests.
- dharmab 4y ago
  Most teams I worked on did not standardize the team's OS or editor. The "canonical" build was a CI server and the development environment was available as a VM or container.
- rubyist5eva 4y ago
  For the love of God no. I had someone commit theirs and it override my preferred setup and even changed my gd font. You're basically telling your teammates: i am forcing you to work my way so shove it.
EmileSonneveld 4y ago
I do the same with with *gitignored*. Handy for output files of tests, and log files. For example: "log_gitignored.txt" or "mesh_transformed_gitignored.stl". I add it to the repository settings, so all collogues have the same behavior.

p1necone 4y ago

This seems like it could potentially be a source of confusion - different devs on the same project would see different ignore behavior.

rjmunro 4y ago
Not really, because they only see differences they have caused themselves, so they know about it.
- xcambar 4y ago
  And so they forget about it.
izietto 4y ago
It is as soon as you forget about that-but, speaking of myself, it is not because I'm aware of the fact that I'm using it
diarrhea 4y ago
As far as I can see, this only comes into play when newly adding files to be tracked. If you created a 'source.file', but your global gitignore ignores all '.file' files, then you'd notice immediately. You wouldn't commit and push because you were unable to add the file in the first place. If another developer has added a 'source.file' and you pulled it in, your global gitignore would not be triggered, since the file is already tracked in the repo.
- CorrectHorseBat 4y ago
  It would also come into play of you add code that generates files which should be ignored, but you don't realize the gitignore has to be updated because it's ignored in your own global gitignore.
  - diarrhea 4y ago
    Very good observation. That's a reason I'm itching to try out an approach akin to this (in a future project): https://jasonstitt.com/gitignore-whitelisting-patterns https://jasonstitt.com/gitignore-whitelisting-patterns

vbezhenar 4y ago

Standard path is ~/.config/git/ignore

toastal 4y ago
You mean $XDG_CONFIG_HOME/git/ignore
- lillecarl 4y ago
  "For writing options: write to global ~/.gitconfig file rather than the repository .git/config, write to $XDG_CONFIG_HOME/git/config file if this file exists and the ~/.gitconfig file doesn’t." Everyone aren't using all the freedesktop conventions, so no.
  - everybodyknows 4y ago
    To supply context: the above quote is from the man page, therefore authoritative. $ man git-config It is however densely conditional wording -- could be simplified.
- vbezhenar 4y ago
  I don't think that XDG_CONFIG_HOME is a thing with Windows or macOS.

alexpls 4y ago

The global gitignore is super useful! I add a “.x” entry to it so that I can create scripts, drafts, etc in a “.x” folder in any of my projects. Wrote more details about how I do this here: https://alexplescan.com/posts/2022/04/17/the-x-files/ https://alexplescan.com/posts/2022/04/17/the-x-files/

sdoering 4y ago
You had me - before clicking - at the url-slug "the-x-files". Loved the content and learned something useful. Thanks for pointing it out. Will be another little tool in my belt.
wonder_er 4y ago
just set this up on my machine! Thank you so much! I'd just been bumping into this problem, but hadn't conceptualized such an elegant solution, so kept fumbling around, adding/moving things, futzing around with git way more than I wanted to. Thank you!

gertlex 4y ago

I've got a slightly different version of that last rule in mine: *.sw? Since I'm messy enough to sometimes end up with multiple of them for a few files. (Also, not messing with flash files in git, or in general...) But have since moved my vim swap files to ~/.vim/swap with `set directory=~/.vim/swap,.` in .vimrc.

fomine3 4y ago
ignoring .swf is a bonus :P

chrisfinazzo 4y ago

Hard agree. Even though I tend to work on only a couple of different kinds of things - at least for now - the global ignore file is a godsend. So good.

tehbeard 4y ago

I heavily advise AGAINST using this for anything apart from OS level file spam (.DS_Store etc). We spent a good part of a day rebuilding a repo after a junior dev. left, when we found out they'd misused global gitignore and hadn't commited several important files due to an ignore they had set for a seperate project. Lessons learnt. Ensure new devs don't use it, and code review on another machine than theirs...

sitzkrieg 4y ago
how did that project ever build on ci :)
- 89vision 4y ago
  but it worked on my machine
  - abustamam 4y ago
    Ship your machine as CI, problem solved /s
    - rubyist5eva 4y ago
      docker wants to know your location
- xyst 4y ago
  hint: there was no CI
  - superjan 4y ago
    I heavily advise AGAINST not using CI. If properly applied it solves .gitignore mistakes and many more, made by those infamous junior devs. On second thought, not just juniors. Oh well.
- TheSoftwareGuy 4y ago

mikl 4y ago

Or simply put the file at the default location for core.excludefile, which is ~/.config/git/ignore on Unixy platforms.