r/programming • u/der_gopher • 2d ago
.gitignore everything by default
https://packagemain.tech/p/gitignore-everything-by-default•
u/Smallpaul 2d ago
“think we’ve all been there. You’re working on a project, making commits, and then suddenly realize you’ve been committing .DS_Store files, node_modules, IDE configuration files, or other junk (CLAUDE.md for example) that shouldn’t be in your repository. Or even worse - environment variables.”
Not really, because most projects start with a gigantic .gitignore these days. From the repo template. Iterate on the template .gitignore and these problems will be few and far between
•
u/lurgi 2d ago
Am I the only person who actually checks what they are adding? I use .gitignore because it saves time, but I never add a file unless I know it’s something I want added.
•
•
u/Smallpaul 2d ago
I check but mistakes can still happen. Misclick in a GUI. Starting with a robust .gitignore (especially for .env files) is a good habit, just as staging files one at a time is.
•
u/thomas_m_k 2d ago
I used to also manually decide which files to track, but I recently started using jujutsu where that kind of approach is heavily discouraged, so I have started to actually write a proper
.gitignore. And I have to say that after the initial annoyance, it is a nicer experience overall. (I still meticulously go through my diff every time before I commit, which in my experience not everyone does.)•
u/novafunc 2d ago
git statuscan hide some things. For example, if you create a new directory, it only shows the new directory and none of its contents.That recently got me when that directory had a subdirectory of binaries builds.
If
git statusshowed something like:
directory/bin/build directory/bin/build2 directory/filerather than:
directory, it could help in some cases.
•
•
u/lurgi 2d ago
Agreed, and I've certainly made that mistake before. However, I do put stuff in my .gitignore (and by now I have a fairly complete one that works for the things I typically do) and after doing the
git add somefolderI review (I know, I know. Nerd) the files that were added and remove any that are not wanted.OTOH, now that I've actually RTFA, I think they have a point. It's a lot easier to describe the things I want to commit (.java, .xml, .txt, .md) compared to the things I don't (uh... anything that isn't those). You still have a potential problem with files that are generated by your build process, where the
!*.gowould have to change to indicate actual.gofiles you wrote. That's true for any approach, of course.•
2d ago
[removed] — view removed comment
•
u/programming-ModTeam 2d ago
No content written mostly by an LLM. If you don't want to write it, we don't want to read it.
•
•
2d ago
[removed] — view removed comment
•
u/programming-ModTeam 2d ago
Please don't accuse people of using LLMs. Just report the post and let us handle it.
•
u/TheBinkz 2d ago
Why ignore Claude.md?
•
u/ia332 2d ago
If you have a CLAUDE.md file you can’t pass off the AI’s work as your own.
•
u/saxbophone 2d ago
Why are you assuming that every commit is a positive assertion by the author that all content contained therein is their own original work‽
This is software engineering, not essay plagiarism-detection.
→ More replies (2)•
•
u/_Sh3Rm4n 2d ago
Additionally, all these "local" files (e.g
.DS_Store) or files specific to your setup (CLAUDE.md) should be in the global ignore file~/.config/git/ignoreor in.git/info/excluderespectively.•
u/JohnBooty 2d ago
CLAUDE.md/AGENTS.md should most definitely be in the repo and treated like source code. It’s where you put basic rules, project structure etc. a lean efficient one is worth its weight in gold. Helps agents stop asking the same questions and making the same mistakes.
Have a local one that is excluded from source control for personal prefs but definitely have a shared one.
•
u/Scavenger53 2d ago
I would never trust that some elses machine has those in the global ignore what
•
u/Smallpaul 2d ago
Why do you need to trust anything? They are responsible for their commits and you are responsible for yours.
If you want to collaborate then you can add file types to a .gitignore.
•
u/Rakn 2d ago
Nah. You can operate like that in a hobby project. But in a large company you usually optimize for developer efficiency across the board. So these ignores will either be in the projects .gitignore file or automatically deployed to your device. Bit you don’t expect everyone to manage such a basic thing by themselves. That’s just inefficient.
•
•
u/AnnoyedVelociraptor 2d ago
I have this for dockerignore. Makes the context a lot smaller.
•
•
•
u/Intrepid-Stand-8540 11h ago
and avoids leaking your .env file into the image.
so many people just COPY in everything and their .env file ends up in the image.
•
u/inotocracy 2d ago
I like when git status and git diff actually show changes. So I'll pass and use git correctly.
•
u/captain_obvious_here 2d ago
Exactly this.
The tool helps you a lot, just pay attention.
Don't automate your commits.
•
u/hugogrant 2d ago
Or stage changes more intentionally?
•
u/SanityInAnarchy 2d ago
Yeah, that was my first thought:
What if we flipped this approach entirely? Instead of allowing everything by default and selectively ignoring files, what if we ignored everything by default and only allowed specific files?
That's... what Git does. It only commits stuff you
git added.Ignoring just means you won't notice files you don't add. Which means you'll have the opposite problem: Commits full of files referring to something you forgot to add, that didn't even show up in
git statusorgit diff.•
u/davidalayachew 1d ago
That's... what Git does. It only commits stuff you
git added.Yeah, but 99% of all students out there were taught
git add ., then never did anything else (until they get lambasted by their senior dev).I know because I was the one who had tutored many of them away from doing that, only to be met with complaints that even the teachers are saying it's fine.
•
u/pohahaha 2d ago
So true…
I usually explicitly walk through each line before committing anything, not an issue at all•
u/yawaramin 2d ago
It’s the gap between ‘usually’ and ‘always’ where mistakes happen.
•
u/pohahaha 1d ago
And you also could forget to “not gitignore” something by that logic?
•
u/yawaramin 1d ago
Sure, you could forget to add a file. But then your app just won’t work, which will be caught by your CI pipeline and then you fix that. If you accidentally commit and push a dotenv file, the app works but you’re leaving yourself at the mercy of attackers.
•
u/pohahaha 1d ago
?? Which attackers? That have acceas to your source in git?
•
u/yawaramin 1d ago
•
u/pohahaha 1d ago
Hm, any serious applications do not allow access to source code though? By using proprietary git servers
•
u/yawaramin 1d ago
The article I linked answers this question. Even private git servers can get breached. And then the attackers can just scan the source code and access anything they find there. If it's S3 credentials, for example? They can help themselves to the private data stored there. All explained.
•
u/pohahaha 1d ago
I.e. if any sane attacker gets access to source code, then breaching it is a matter of time. Also, who in the world even uses any sort of credentials in a written git-repository available format?
•
u/yawaramin 1d ago
Dotenv files are a super common way of injecting secrets into many apps during local dev. And they can get committed into the repo accidentally, just as described in OP.
This is why in my company I've recommended using 1Password to inject the secrets instead. This way dotenv files don't contain anything sensitive at all.
•
u/msqrt 2d ago
This doesn't prevent that. I find that it's typically easier to list the kinds of files I do want (code, .md, config formats) than the ones I don't (caches, intermediate results, databases, UI settings, ...) because the former set doesn't really change after your initial commit. This also keeps git status less noisy even without adding every single weird extra file to gitignore.
But yeah, it's still unorthodox and I only do it for my personal projects where I mainly want VC to keep some kind of history and it doesn't have to be very detailed.
•
u/SchwiftySquanchC137 2d ago
Yeah i just feel like then you could run into the opposite problem, accidentally miss some source code or necessary file because you forgot to add it to your gitignore and git status literally never tells you. Theres basically no way to notice the problem short of just randomly noticing it, or cloning a fresh repo and finding a build error (or ya know ci or whatever might detect it, depending)
•
u/der_gopher 2d ago
Yes, but this you have to do before every commit, while careful gitignore does automatically.
•
u/boowhitie 2d ago
I think you're greatly over-estimating how often this happens. You should be very intentional about what gets committed and what gets ignored, it's not hard.
•
u/Smallpaul 2d ago
Git itself ignores everything by default. So you are just adding another layer. And then people will get annoyed editing that file so IDEs will add some automation to make it easy and we will be back where we started.
The other problem is that as soon as you use any wildcard you risk checking in files that you didn’t mean to. E.g. short term logging traces or one-time debugging scripts.
•
u/HQMorganstern 2d ago
Checking things in is a far more common operation than leaving things out. Frankly it's common sense to keep
git add .usable, since due to lower friction it's what will be used.•
u/Smallpaul 2d ago
‘git add .’ Is the problem.
Use file by file staging as an opportunity to review your our own code or your agent’s code and ensure that what you are committing makes sense.
•
u/SchwiftySquanchC137 2d ago
I couldn't believe when my coworkers looked at me like I was crazy for individually reviewing each file as I added it. Wonder how all those extra print statements, random unrelated changes, etc keep ending up in their PRs... like yeah it still gets caught eventually, but i prefer to put forward the best version of my code for review, not rely on my coworkers to sift through my own laziness.
•
u/HQMorganstern 2d ago
I don't want to, I want my tools to be easy to use and remove friction. I have tools for reviewing they're also to use and add only important friction that's actually helpful.
Your point about adding as a mini review was immediately clear, it's just not a good idea when it integrates with 0 of my pre commit hooks and post commit checks, which allow me to bulk review with a high degree of certainty.
•
u/yanitrix 2d ago
Your point about adding as a mini review was immediately clear
what mini review? It's literally reading the files you wrote. Not even reading the files, just reading the file names.
•
u/Smallpaul 2d ago
What do “pre-commit hooks and post commit checks” have to do with code reviewing?
Good tools add friction at the points where it is useful. In fact the whole point of this article is that the writer is adding extra friction to adding data types to git.
•
•
u/lenswipe 2d ago
Git itself ignores everything by default.
uhhh what now
•
u/FaceyMcFacface 2d ago
It only tracks what you explicitly add. That's how I read the comment.
•
u/lenswipe 2d ago
yeah I guess that's a fair comment, but it doesn't ignore by default. the files still appear and git still sees them, it just doesn't track them. so if you're the kind of person who just does
git add .you'll probably get burned by that. that said I would always add you should be reading your diffs (even just a cursory glance) anyway.•
•
u/Smallpaul 2d ago
The other guy interpreted right. Git won’t manage a file unless you added it to the index.
•
u/lenswipe 2d ago
it won't manage it, but it doesn't ignore it by default.
thanks for the downvotes btw - means the world to me 🥰
•
u/boowhitie 2d ago
You are correct, ignore has a specific, well-defined meaning in a git context, and these people are applying general English definitions.
•
u/lenswipe 2d ago
yeah I'm not trying to be a dick but "doesn't track" and "ignores" are very different things in git world
•
•
u/Smallpaul 2d ago
Git status and git add . Don’t ignore them, but git commit, diff, log, push, all do.
•
•
u/wanze 2d ago
It sounds like you're making this overly complicated, because you insist on using
git add ., but you don't know about-u?If you do
git add -u ., git will only stages changes to already tracked files. You'll never accidentally add a file you didn't want staged.Do
git addwith the specific files you want once, and thengit add -u .afterwards (if you insist on not being specific about what you want to stage).
•
u/Kanegou 2d ago
I think we’ve all been there.
No. Not at all. Never happend to me in my 15+ years of using git. Only a moron uses git add . blindly. But i broke build multiple times cause gitignore caught a file that should be included.
•
u/SchwiftySquanchC137 2d ago
Seriously, how is no one bringing up that using gitignore in this way leads to a far worse problem, you'll inevitably forget to add a file, and literally nothing will ever notify you of it aside from CI, another dev pulling your update, or you cloning a fresh repo yourself. Particularly for solo projects, this is just asking to permanently lose important files when you switch laptops and wipe your old one or something. You simply will never notice the file missing because your build will still work until you clone fresh.
Id much rather leave open the tiny possibility that I commit an extra file, than leave open the almost certainty that ill forget to add some obscure but important file to the gitignore.
•
u/garfield1138 2d ago
Sometimes I still think of that consultant that committed node_modules. We paid him about $1000 each day.
•
u/subone 2d ago
I feel like I've committed a wrong file (not secrets) maybe once in my entire life. Aren't you reviewing every file again before commit? I tend to go overboard with my changes, so I always review to see if I added too much.
Anyway, I think this is the silliest idea. So, instead of potentially forgetting one time when an ignored file is created, you have potential every single time you create any file that you'll forget to add it to the ignore-ignore list and check-in a broken change. Also, more edits to the ignore file is more likely to generate some mistake there. Frankly, you're opening yourself to up to a broader range of issues just to avoid carefully looking at your files, when in fact you are still going to have to manually carefully manage your files even more so now.
•
u/SchwiftySquanchC137 2d ago
Thank you, this approach adds a much scarier problem, actually losing your data/code because its not on github or whatever, and git never notifies you. To get around one potential easily fixed commit of an extra file, youre opening yourself up to the most critical failure of version control?
•
u/sweetno 2d ago
Committing inappropriate stuff is only possible if you don't review what you're committing, which is a sin.
•
u/levodelellis 1d ago
Sometimes I commit a dozen times a day (usually refactoring), and sometimes the project uses tools that generates files outside the build & ignored directory, sometimes they are added and assumed will not be pushed. Then someone says hey can I see some of the things you refactor and suddenly you have random html and and json files that you didn't mean to commit on the server
Maybe having inappropriate stuff in a PR is a sin, but I don't think a wip branch is that big of a deal
•
u/Sokaron 2d ago
Agreed with others that this mostly solves a problem that's already solved if you're reviewing your diff prior to committing which you should be doing anyways.
Disagree on the note that AI files like CLAUDE.md shouldn't be committed. If you make the base assumption that people will be using agents to contribute to your repo (that's a pretty damn good bet) then CLAUDE.md is how you set baseline expectations for agents to follow. Plans I am less convinced by, feels like markdown noise, but I've seen arguments both ways.
•
u/relative_iterator 2d ago
Started a project solo recently and then had two devs join in later. Claude/agent files in the repo made that pretty seamless for a lot of coding preferences I set up.
•
u/garfield1138 2d ago
Stupidest idea I've seen in a while. Just hoping this is some kind of shitpost.
If not: Try to understand how to use git.
•
u/der_gopher 2d ago
> The technique isn’t necessarily the right choice for every repository or developer, but is an alternative to explore.
→ More replies (1)
•
u/yanitrix 2d ago
You’re working on a project, making commits, and then suddenly realize you’ve been committing .DS_Store files, node_modules, IDE configuration files, or other junk (CLAUDE.md for example) that shouldn’t be in your repository.
No, I read my code before making a pull request. And I do multiple commits and then it's ultra easy to spot the files I shouldn't commit. Even if I do commit, then rewriting history is trivial. Seems like a solution to a non-existing problem.
•
u/Glad_Position3592 2d ago
Yeah, in larger developed work environments it’s not really an issue. It’s much more common for this to happen in startups, particularly in the early stages. When you’re working on several different projects at the same time as the only developer and you’re making 10-20 commits a day, it’s easy to accidentally commit things you didn’t intend to
•
u/yanitrix 1d ago
I havent' worked at startup but I guess people still make a PR and do code review at these companies (but I may be wrong). So reading your code before you commit is the time you spot the issue, and rewriting the history is like 3 git commands. Even faster if you're using a gui. I think the only people that would have that kind of issue are solo coders who just push to main in a public github repo.
•
u/umtala 2d ago
No thank you.
I'd much rather something be tracked accidentally, rather than accidentally not tracked. If it's tracked accidentally then you have history that you didn't need. It's an excess of something good. Perhaps it will use up storage, but storage is was cheap.
On the other hand, if it's accidentally not tracked then you lose history and potentially lose data.
The exception is for secrets but that's easy to solve by putting them all in one place (preferably outside the repository).
•
u/BipolarKebab 2d ago
Breaking: village idiot can't avoid using `git add -A`, blows his fingers off to enforce discipline
•
u/South_Survey_2088 2d ago
For git, this seems kinda pointless since you should explicitly add things. If you just glob add everything without looking, you are just a clown and accidentally committing files is the least of your issues.
For jujutsu on the other hand, I kinda like the whitelist approach, because it doesn't have a staging area and adds everything by default.
•
u/Nicksaurus 2d ago
It's easier to add stuff by mistake with jujutsu but you should still be reviewing all of your changes before pushing them. I often do a git-style workflow by using a temporary change in place of the git working tree and extracting just the changes I want into a separate changeset when it's time to 'commit' them
•
•
u/boowhitie 2d ago
The whole point of staging is to only commit intentionally. Git has an untracked state specifically because it is useful. If you ignore everything by default, your tools cant tell you when you've forgotten to add a file. You know what's more embarrassing than committing secrets to git? Having another developer not be able to build because needed files are missing because of your dumb global ignore. Or not being able to reproduce an old build.
You also should commit your claude.md, if you are afraid that is the only thing that is going to identify your repo as ai slop, I've got bad news for you.
All that said, I have found one use for a global ignore: my dot files repo. I have a versioned environment that I can easily move between machines, and changes on one get moved to the others the next time I use them. In this case I don't want everything in my home dir to show up, so I ignore everything and add explicitly particular files and directories.
•
•
u/Emergency-Event4415 2d ago
To the people saying “Who tf just git adds everything? You should check what you add.”
Yes, but you clearly don’t work with engineers/scientists who learned programming/git later in their career just to run calculation scripts.
I’ve seen personal photo folders somehow committed.
•
•
u/Affectionate-Egg7566 2d ago
I don't like this method. I think it is antithetical to the idea of small, logically coherent commits. I also want to know which files (if any) I have left untracked. git add -p makes accidentally adding a file a non-issue.
•
u/burnsnewman 2d ago
Nonsense. It's useful to know what changes in your folder. Just review what you stage and commit. Make it intentional. And don't fix things that aren't broken.
•
u/stianhoiland 2d ago edited 2d ago
A lot of people seem to use git because they have to, not because they want to. It makes sense, and will likely continue to be this way. But when you use git because you want to—which entails understanding its function and its benefit and especially the pitfalls of not using it—then you gain ownership of its use and this in itself gets rid of a whole host of antipatterns.
•
u/EC36339 2d ago
I'll screenshot this and use it on my crusade against squash merges.
•
u/SchwiftySquanchC137 2d ago
What's wrong with squash merges? You dislike having a clean commit history that isnt full of junk your coworkers put like "fix bug". Or maybe you prefer when git bisect doesnt work, because rather than every commit being a working state, you actually have faaaaar more non working commits? I truly cant imagine why you would crusade against squashing, I seriously doubt having every non working intermediate step of a PR is useful more often than its hurtful.
•
u/semajames 2d ago
My biggest problem with squash merging is it rewrites history and breaks PR stack flows.
•
u/EC36339 1d ago
History is sacred. Every rewrite of history breaks something in subtle ways. Squash merges, rebase before merge, it's all harmful.
I've now even come full circle on rebase. When I need to merge the trunk into my feature branch, I use
git merge. Full stop. No more history rewriting. If I have to make an extra commit that just fixes one line in a previous commit, I make that commit and keep it. No more squashing to "keep history clean".However, in a team, I would never make a rule that bans rebase. It's the equivalent to recreating a branch from scratch. How people manage their feature branches should be peesonal choice, within reason, as long as they deliver quality with usable history.
And of course, I merge my festure branches with merge commits.
History has to be honest at all times. This also means: No red tape that makes commits feel awkward. No standardised commit message format. Commit whenever you feel like and write in your commit messages whatever you think should be in them. Polishing commits after the fact is dishonest and destroys information that could be useful. It destroys evidence that maybe one day you wish you'd have to investigate a bug.
This may be controversial, but: I normally just use AI to write commit messages. Most of the time it is more accurate and honest than my own framing. And when it isn't, I can amend it (although that's, technically, history rewriting, too...)
Merge commits to trunk shall have the same message as the pull request title and description. And those have to be polished but honest, and always with an elevator pitch that explains the "why" more than the "what". This is where AI sucks, at least its default behavior. And if you do use AI here, at least read the descriptions completely and review and edit them.
Don't wanna see the dirty commits made underneath the shiny pull request merges? The "junk", the inherent non-linearity? Try this:
git log --first-parentNeed to cherry-pick or revert a whole pull request merged with a merge commit? Git has you covered.
git revert --m 1 SHA git cherry-pick -m 1 SHAThe cherry-pick squashes all commits from the merge into one. So it's a bit like a squash merge. I didn't like that at first, but in this one case it's actually better. Cherry-picks are already ugly and a last resort.
"But then everyone needs to learn advanced Git commands and git gud at using Git. Won't anyone think of those poor junior devs? Not everyone is a rockstar developer"
Your average junior dev is probably more motivated to properly learn the tools of the trade, of which Git is one of the most important, than us old farts who grew up without version contol (or worse: Any VCS that isn't Git...). My favorite article that destroys all the arguments for squash merges was written by a junior dev. Listen to your junior devs, gramps, you might still learn something new! Also, everyone hates "rockstar developers", but what are you gonna do once you become one?
(Sorry this got a bit long, and it's not a reply personally to you. But I said it, I'm on a crusade...)
•
u/EC36339 1d ago
I should add one thing:
The developer that is "not so good at using Git" that you should worry about is neither your junior dev, nor your senior who doesn't like learning new things.
It's your AI coding agent.
If your coding agent squash-merges a PR or rebases a branch, and something goes tits up, then you're stuck without an undo button. You are royally screwed.
Yes, I know, there's backup, and locally you have
git reflog, and orphan commits probably don't vanish instantly from the server, if they ever do (how DOES retention of orphan commits actually work?!), and you probably don't want to allow AI to merge PRs, or merge anything.But if your agent did a bad merge commit with plain old
git merge, you can revert it. Disaster averted (or REverted), without even a history rewrite. Or you can rebase or reset and force push and make it "never happened", but agit revert -m 1works just fine without the risk of fucking things up even more. And as a bonus, you can revert the revert.So "history is sacred" and "merge commits everywhere" is not only an honest and simple doctrine, but also "AI safe".
•
u/EC36339 1d ago
History isn't "junk". Read this, and if you still disagree, you'll at least be wrong in a more informed way.
https://lucasoshiro.github.io/posts-en/2024-04-08-please_dont_squash/
•
u/Anders_A 1d ago
Haha this is the dumbest suggestion to solve a non issue 😂. Just look at what your commits contains before pushing them somewhere ffs.
•
•
u/kimoisune 1d ago
review before commit, no?
historically, only build artifacts are to be excluded (build/, out/, etc). nowadays, you have LSP cache, editor config, vim_autism_rc, .DS_store_WTF, node_boobies_or_whatever_they_call_it and SLOP_AGENTS.md (for sleeper slopping). i kinda get it. but the first you should do is dropping the usage of git add -A. review each file before add them to staging and review them before commit the stage. modern editor have dedicated git management panel/tab and equipped with visual diff functionality. and for the love of god, style your changes to the provided coding style guidelines or use the included styling tool before open a merging ticket.
•
•
u/KryptosFR 2d ago
Not needed if you have discipline and I know what you are doing. Commit frequently. Make sure each commit is shippable. Organize your work to be split into small actionable pieces.
Don't rely on tools if your work practices are a mess. Fix those first.
•
u/Automatic_Friend3744 2d ago edited 2d ago
while i don't dislike the idea, i think it's better to have a project structure where you know code should only be in a certain directory (eg: src/) so you can have a simple gitignore like:
*
!.gitignore
!src/
!README.md
that way you still get the benefit of not accidentally committing scratch/test/env/etc files, but you also still can see what has been added. it works quite nicely on larger projects where you might have all sorts of misc data files/dumps locally in the project root that should never be committed.
•
u/dronmore 2d ago
IIRC whitelisting
!src/is not enough as it only whitelists the directory, and none of the files that it holds. You need another rule for files inside thesrc/folder, and yet another for subdirectories, and then to apply the pattern recursively. Your.gitignorewill look more or less like this:* !.gitignore !src/ !src/* !src/model/ !src/model/* !src/view/ !src/view/* !src/view/html/ !src/view/html/* !README.md
•
•
•
•
u/levodelellis 1d ago
I'm fine with a global pre-commit hook
#!/bin/bash
if git diff --cached --diff-filter=A -z | grep -q "Binary"; then
echo "No Binary Allowed"
exit 1
fi
•
u/apple6524 1d ago
I think the problem arose from tutorials, I remember being taught to do 'git add .'.
•
•
u/VisualAromatic6226 16h ago
The "git add -f" friction is a feature, not a bug. Every time I've been bitten by a leaked secret, .env lived in a subdirectory that got added accidentally by "git add ." because the parent was whitelisted.
Making the default deny and forcing an explicit action to commit something new changes the shape of mistakes. You go from "I accidentally committed a secret" to "I got an error because I tried to commit a new file type". The second is 100x recoverable.
One addition to the article's approach: pair it with a .gitattributes filter or a pre-commit hook that strips known secret patterns on commit. Belt AND suspenders.
•
u/Fitnexa_Life 6h ago
The funny part is, this only applies to untracked files, so the repo’s ignore policy changes halfway through its history.
•
u/ggchappell 2d ago
Okay, I'm changing all my .gitignore files over to this style. But not because I have a terrible problem of accidentally committing things I don't want to. Rather, because this is a better way to do it. It's a different way of thinking about what a .gitignore file is. It's simpler and clearer. It's the way they should have been in the first place.
•
u/SchwiftySquanchC137 2d ago
I would reconsider. If you add an important file with a new extension, and you forget to add it to the git ignore-ignore, then you might never know that you dont actually have that file backed up. Its literally opening up a critical failure point, its faaaarrr preferable to accidentally commit an extra file (which never happens anyway) than to never actually track a file in version control and back it up. Its literally adding a catastrophic failure mechanism thats fairly easy to hit for absolutely no gain.
•
u/ggchappell 1d ago
Well, I will think about what you're saying. But for the time being, I'm calling it an experiment. We'll see how it goes.
•
•
u/slaymaker1907 2d ago
See now things start to get extremely confusing when there are some *.go files which actually do need to be ignored.
•
•
u/wknight8111 2d ago
Honestly I really love this approach. When you think about a normal software project the amount of things that you need to include is relatively small (source code files, scripts, docs, build metadata) and the list of things you need to exclude is relatively large (build artifacts like object files and executables, generated code, generated docs, test and benchmark results, code coverage reports, third-party binaries, metrics and analysis results, user-specific editor files and settings files, secrets and local configs, temp files, crash dumps, debug symbols, cache files, profiler output, packaging/publishing artifacts, signatures and keys, db backups, etc).
Blocking everything by default is safer, and only allowing the few things you actually want to commit would be cleaner and easier to maintain overall.
•
u/toggles03 2d ago
I like the idea of being intentional about what is committed, but I also have to say that I’ve never accidentally committed tons of useless files because I review what I’m committing.