I downloaded a little plugin the other day; you might use something like it yourself, if you're a super nerd (sorry..): it's called disable-javascript. It's a browser addon that I use in Firefox to maximize speed and minimize annoyance when visiting one of the bajillions of overloaded how-to and fake-news and cooking websites, where by "overloaded" I mean there's 999 ads, and auto-playing videos and pop-ups and newsletter subscriptions all vying for my attention when all I want is basic content. However, the addon also breaks many things you may want to use on the interwebs. You've been warned.
Anyway, I was playing around with this addon - first I had it in "default on" mode (meaning JS is allowed), and so when I visited annoying websites, I would add them as an "exception", which would mean they would have javascript disabled. But then I realized that was a losing battle, and it would be much better to use "default off" mode which disables JS everywhere. When I made the switch, however, my list of "exceptions" from phase 1 stuck around, and now they were exceptions in the opposite direction; that is to say, all the websites I wanted to block were now being permitted. It turns out the exceptions list has no concept of whether sites should be blocked or allowed - it just does the opposite of whatever the current setting is. That's a little inconvenient for people like me who can't make up our minds. đ
Now, what better to do when you find a problem than SOLVE IT?? Indeed dear readers, so I hunted down the code, forked the project from Github, and started trying to add a flag for "block" vs "allow" locally. Part of the setup was npm install
which generates a local directory node_modules/
, full of libraries that you most definitely (probably, except in weird cases, I guess) do not want to track in Git. Generally this would be accomlished by having a row in the project's .gitignore
, telling Git not to worry about anything in node_modules/
, so that when you do git status
it doesn't say that everything in node_modules
is untracked, or when you do git add .
it doesn't try to add anything in node_modules
, etc. But the .gitignore
for this project (which existed! that was my first question) mysteriously did not contain any mention of node_modules
. Had previous contributors, including the main creator/maintainer, all just quietly and carefully ignored it themselves in their brains?
Idk, I'm not a mind reader (as much as I sometimes try to be). Being the helpful human I am though, I made a pull request to add node_modules
to the project's .gitignore
. Now, here is where the plot thickens! The maintainer replied to me (very kindly, I must add - I opened a pile of PRs and issues at the same time and the maintainer was very patient with me đ) to explain that, while they agree that node_modules
should not be committed, I should actually have it in my global git config to ignore it everywhere. "Best practice!" they said. (Though not actually quite like that, alone as a sentence or with an explanation mark. That is me taking liberties with the editing.) Wow! I thought. I had never heard of such a concept, to centralize things like a python ENV or node_modules to a global .gitignore.
So I searched the internet high and low for "best practices on global vs project gitignores". Just kidding, I searched for 2 minutes[1]Ⲡ[2], before realizing the internet in general was not going to offer trustworthy answers and I had better find a true source of truth, which ended up being man gitignore
. The relevant lines are there for you to investigate. The section I wanted was about "Which file to place a pattern in", and the most important sections were the first and third ("other repositories" means other developers local copies of the same project):
* Patterns which should be version-controlled and distributed to
other repositories via clone (i.e., files that all developers will want
to ignore) should go into a `.gitignore` file.
* Patterns which a user wants Git to
ignore in all situations (e.g., backup or temporary files generated by
the user's editor of choice) generally go into a file specified by
`core.excludesFile` in the user's `~/.gitconfig`. Its default value is
$XDG_CONFIG_HOME/git/ignore. If $XDG_CONFIG_HOME is either not set or
empty, $HOME/.config/git/ignore is used instead.
I had a real hard time with the first sentence. My problem was interpreting "patterns" to mean "the actual files represented by the patterns". So I thought it meant "Files which should be version-controlled ..(ie, those that all developers will want to ignore)..." which is utterly contradictory. Either you want them version controlled, or you want them ignored. You can't have it both ways people! I thought maybe they forgot a "n't" at the end of "should". I went on a long voyage reading about how to contribute to git using the mailing list so that I could fix the manpage, before eventually realizing that when it says "Patterns which should be ....", "Pattern" literally means the actual plaintext word in the .gitignore file and not the file itself. -__-
Luckily though, now we can go back to business with the disable-javascript project, because I have it on good word that my pull request actually does make sense, and if I love anything, it's being right. đ (Shh, don't tell.)
In summary:
- text editor-specific or operating system-specific files go in global git config to ignore
- project (and therefore language)-specific files go in project
.gitignore
to be committed and shared with fellow devs working on the same project
Cool beans kiddie winks, thanks for hanging around! Also, make sure you know what you're talking about before emailing the whole mailing list of git. Heh, that would have been awkward.
During my 2 minutes of searching I found this reddit thread, which I now wish desperately to answer to help the next me who comes along, but the thread is closed. PUH. đĻ âŠī¸
Also, can you tell I figured out how to make REAL FOOTNOTES?! Very cool. So much better than my haphazard asterisks system. I might have to go through old posts and fix them up. đ âŠī¸