alt.hn

6/18/2026 at 10:29:20 AM

.gitignore Isn't the only way to ignore files in Git

 https://nelson.cloud/.gitignore-isnt-the-only-way-to-ignore-files-in-git/

by FergusArgyll

6/18/2026 at 7:59:57 PM

Fun article, but it leaves out my favorite "almost ignore" feature in Git: `.gitattributes`.

This file lets you specify that git should "ignore" the diff from certain files. For instance, Node projects have a `package-lock.json` that is pure noise from a Git standpoint (it's just massive amounts of diff specifying specific versions of libraries, and the real human-readable version is in a separate `package.json` file).

With `.gitattributes` in the root of your project, you can just add a line:

`package-lock.json -diff`

Now, that file will still get staged/committed (which you want) ... but when you `git diff` you won't see the massive amounts of pointless diff in that file.

by hungryhobbit

6/18/2026 at 8:13:04 PM

> that is pure noise from a Git standpoint

It shouldn't be noise. Don't update it if you're not intentionally trying to, otherwise you're exposing yourself to supply-chain risk for no reason. If you are regularly getting unexpected `package-lock.json` changes then you are doing something wrong.

by clates

6/18/2026 at 8:16:07 PM

It's not about unexpected changes. It's about DX in git CLI. You don't want to see massive diffs that are basically unreadable for humans, you just want to see that the file changed.

by po1nt

6/18/2026 at 11:36:56 PM

> you just want to see that the file changed

I check the diff for uv.lock (Python counterpart of package-lock.json) every time I merge a PR. It is important to know which direct or transient dependencies have been updated. We don't blindly bump all dependencies to the latest versions (you shouldn't either).

by selcuka

6/19/2026 at 2:16:25 AM

Python packages aren't quite so insane on transitive dependencies. The diff of package-lock.json can be novel length.

by panzi

6/19/2026 at 5:13:45 PM

write your requirement.txt files via

    pipdeptree --freeze
to see this clearly

by gjvc

6/19/2026 at 2:59:57 AM

same - I check the changelog for every major (== minor if v0) and some minor version changes in most of my projects, including at work. I've caught quite a lot of would-have-broken-something changes, and opportunities for fixes/optimizations/etc by doing so. and sometimes they mention fixing a bug we didn't know we had, so we learned about it early before it corrupted too much data.

by Groxx

6/19/2026 at 5:13:11 AM

It's nice to have that luxury, we just don't have the manpower to devote to that. Major versions sure, otherwise it's just update and run test-suite and some smoke tests.

by Maxion

6/19/2026 at 5:45:21 AM

it helps a lot if you make an effort to keep your dependency tree relatively small

by Groxx

6/19/2026 at 7:27:20 AM

We are talking about npm here... Any framework like React, Vue, Angular, Svelte, etc. is going to pull in hundreds or thousands of packages. I just checked one of the smallest web projects I have (5 dependencies, no framework) and it has 265 packages In package-lock.json. My personal website (vite + nuxt) has 1171.

by TonyStr

6/19/2026 at 7:46:50 PM

If your diffs are too large to review your project structure needs change. I go by the broad statement that EVERY line should be read, understood and explainable by the developer.

For critical files like package-lock.json I'd also expect developers to explain why a library was added or a version was changed and the impact of the version change. The lack of such basic hygiene is why supply chain attacks are so common these days.

by jitix

6/18/2026 at 11:10:44 PM

But it's not always massive, it's a good practice to see what the diff is and ensure there is no weird dependency (aka supply chain attack) showing up in there.

by jeromegv

6/19/2026 at 7:01:15 AM

In my opinion you have no chance of identifying supply chain attack like this. It's not like you will see "evil-package": "*" in there. Supply chain attacks happen by appending obfuscated code deep into dependency no one knew you had in the first place.

by po1nt

6/19/2026 at 9:23:59 AM

Are you saying "as a developer, you don't want to see what code you ship as transitive dependencies"?

I guess it's the norm in the software industry, but that's slightly irresponsible.

by palata

6/19/2026 at 2:25:33 PM

It’s too much code. Maybe companies are able to handle this, but as a solo dev it’s completely infeasible.

I could just not use those deps, but then I won’t be able to build anything interesting. The software industry has historically relied on being a high-trust society; I don’t know what will happen if that is changing.

Rewriting every dep with Fable for every project, maybe.

by Filligree

6/19/2026 at 11:23:44 PM

There is a big difference between completely YOLOing your dependencies and deeply reviewing all their code. It is a gradient, by acknowledging that you ask git to hide the file because you consider it "noise", you say that you are on the YOLO far end of the spectrum.

Every dependency adds risk, the goal is to minimise them. If you include a dependency for something that you would code in 20 lines, you should at least wonder if it's worth it or not. If that dependency pulls 5 transitive dependencies itself, probably you should go for the 20 lines.

As you say, sometimes it's impossible to track because there are so many dependencies (thanks to modern package managers that make it so easy). But at least you should see that your dependencies are completely out of control. If you ship an app where 95% of the code comes from dependencies you have never seen, you may as well have vibe-coded the app.

> The software industry has historically relied on being a high-trust society; I don’t know what will happen if that is changing.

I very much disagree with that. Most software is bad and shouldn't be trusted.

by palata

6/19/2026 at 10:48:36 AM

You know what’s bad DX? Your company’s product having a massive security breach, people stop using it, and having to lay off all the software engineers

by StarlaAtNight

6/18/2026 at 9:32:56 PM

DX = ? Developer experience maybe?

by gpvos

6/18/2026 at 10:21:22 PM

Yes

by sisve

6/18/2026 at 10:46:10 PM

The point is that it should not be massive.

by nine_k

6/19/2026 at 4:48:39 AM

Tell that to the NPM folks.

by scrame

6/19/2026 at 12:52:18 AM

It's a CLI. DX is not the only concern. What about scripts that expect the default git behavior?

You could argue "those scripts are dumb then! outta my way!", but then you shouldn't be using a CLI for whatever it is you're trying to do. If you insist, you can just grep or use the --stat option.

We already know the git CLI has plenty of antifeatures like this. It is up to the devs how they want to proceed, but it doesn't change the fact that hiding things is a footgun.

by sublinear

6/19/2026 at 7:09:32 AM

You can suppress the git attribute system if you need default settings. I wouldn't call it "antifeature" but customizability as git was always supposed to be used with CLI, this is just a way to make output less verbose.

by po1nt

6/19/2026 at 3:34:19 PM

It also directs Github to automatically collapse those files to the "Show Diff" interface by default. I'd still call the contents of things like lockfiles, protobuf output, big JSON blobs, etc, "noise" when reviewing PRs for code changes, but that doesnt mean I dont look at them.

by kortex

6/19/2026 at 1:28:00 PM

I think you're missing the point there. It's like I need to commit my project files for the project to compile, they're in xml format so they're human readable. But that doesn't mean I need to see the diff because I'm not going to review them

by ChrisRR

6/19/2026 at 1:30:54 AM

People are jumping on it being an important file to review. You don't want to ignore the diff.

Even if that's true, you definitely do not want to attempt merge two lock files, and using the .gitattributes file to set the merge strategy is a good idea!

by gugagore

6/19/2026 at 6:42:27 PM

There are also "semantic" diff and merge tools for a variety of languages, and a few specialized for JSON. That stuff was always pretty niche, but it's becoming more popular with AI agents and not wanting to or not being able to review every merge by hand.

by gwerbin

6/19/2026 at 3:48:05 AM

eg.

    config.json merge=ours

by fragmede

6/19/2026 at 8:23:18 PM

thank you for being the first in this thread to actually prescribe what strategy to use, its been infuriating reading thru but not having the same level of knowledge

by swyx

6/18/2026 at 10:39:12 PM

package-lock.json shows all your transitive dependencies, package.json just shows your direct dependencies. It is simply not true that the latter is "the real human-readable version". They serve different purposes and it is dangerous to say you can always ignore the diff in your lock file.

by phinnaeus

6/19/2026 at 7:17:05 AM

To me it still sounds like a build artifact, and not source code: yes, you want to keep it and track changes to it, but freeze tools should allow one to easily get a reproducible build of package-lock.json too (eg. by passing a timestamp, it should be able to regenerate the lock file with latest-as-of-timestamp).

Maybe they do — I am not too deep in JS ecosystem — but that should be the basis of a true SBoM (generated, static artifact tied to a release build) and reproducible builds (able to regenerate byte-for-byte identical artifacts from actual source of truth which is your package.json).

by necovek

6/18/2026 at 11:25:39 PM

as someone who deals with dep upgrades and forensics when trying to figure out a bug I would get _so mad_ if `git diff` didn't show the diffs to lock files.

I get what you're saying about it being line noise but when you need it you need it!

by rtpg

6/19/2026 at 3:13:50 AM

and in today's world of constant supply-chain attacks, you do probably _do_ need it!

We've adapted: - our CI and git hooks so that our dependency or .lock files are visible when they change, and error if they change inconsistently - and our team procedures to confine dependency updates to dedicated commits

The idea being that when you see one of those "messy" .lock file changes...you were expecting it. If you see one and are annoyed by it (like OP) that's actually a waving red flag that a dependency changed.

by rablackburn

6/19/2026 at 11:52:03 AM

Better: set up a git diff driver so you see the semantic changes, not line-by-line changes.

by rlpb

6/19/2026 at 8:32:07 PM

It also leaves my favorite way of ignoring files in Git: actually just ignore them yourself and never use shortcuts that break that (like "git commit -a" or "git add .")!

by necovek

6/19/2026 at 8:47:13 PM

[dead]

by tourist2d

6/19/2026 at 4:18:47 PM

Sounds like a powerful feature for subverting code review…

by BobbyTables2

6/19/2026 at 4:23:05 PM

You should 100% track package-lock.json, and I'll go a step further and say you should most likely track node_modules too.

by nananana9

6/19/2026 at 8:33:33 PM

If the underlying infrastructure does not provide reproducible builds, I'd suggest you should instead fix that.

by necovek

6/19/2026 at 10:15:41 AM

This is probably the most batshit insane insecure advice I've ever read on Hacker News ever. And everyone is wondering why NPM based attacks are so prevalent? Advice like this is being followed.

by lloydatkinson

6/19/2026 at 3:39:37 PM

I think you misunderstand the functionality. It doesn't ingnore the diff completely. it just replaces the full contents with "`Binary files differ"

> Use -diff to completely hide the internal file content during a diff. Git will only report `Binary files differ` if the file changes.

Same like you would binary files. It's still good advice to actually review the lockfile changes at some point.

You can also apparently write transformers to make it more human readable.

by kortex

6/19/2026 at 8:24:38 PM

Explain the attack that gets mitigated by reading the diff of a lockfile?

Every major npm attack I can think of essentially follows the pattern of "version X.Y.Z is secretly evil". How does seeing package@X.Y.Z in your lockfile alert you to that?

by smrq

6/19/2026 at 2:31:14 PM

It’s fine imo, you’ll still see the diffs in PRs before merging, but majority of the time it’s just noise when developing locally. LLM agents also use git diffs frequently, why spend 10x the tokens analyzing package lock diffs instead of actual business logic changes.

by nujabe

6/18/2026 at 4:02:40 PM

The global/user wide exclude is a feature that should be more widely known. I frequently have people submitting changes to add their IDE/OS/AI/... files to every project's .gitignore. They are almost always pleasantly surprised when I tell them that they can add them to their standard configuration and have them ignored everywhere without bothering every project and without risk of accidentally committing them on a project where they haven't updated the .gitignore yet.

My general rule is that in-repo .gitignore should only be used for repo-specific things (build outputs, dependency folders, ...) and most user tools should be in their own user config.

by kevincox

6/18/2026 at 4:10:57 PM

I've always added it to the project's gitignore because I want to make sure nobody else adds those to the project, either, out of ignorance. I'm mainly doing it out of kindness to them, because I am definitely removing them from git again and it's going to cause them some pain.

In the future, I think I might just be less nice about it. I dunno.

by wccrawford

6/18/2026 at 6:47:25 PM

This is how I see it. The more contributors you have with a code base, the larger the possibility that one person will mistakenly commit something that could have easily been avoided by just preemptively adding it to the .gitignore.

You cant preempt every file or folder, but its almost no effort to catch the obvious ones.

by xboxnolifes

6/18/2026 at 6:08:59 PM

Yeap. To reduce pain, you need to work with reality rather than ideals. If you work with a big group, you either add a few lines into your gitignore, or you write code to check for those very same files in your CI/PR system, because you're tired of reversing commits and rejecting PRs because you're the only one that cares about a few extra files.

by nomel

6/18/2026 at 6:45:45 PM

This is how I see it. The more contributors you have with a code base, the larger the possibility that at least one person will mistakenly commit something that could have easily been avoided by just preemptively adding it to the project .gitignore.

You cant prompt every file or folder, but its almost no effort to catch the obvious ones.

by xboxnolifes

6/18/2026 at 5:32:56 PM

I’m not sure kindness is the best framing. At least, not in terms of being nice to any particular person who might commit unwanted files by mistake.

It’s one of several tools a project can use to ensure quality, alongside eg linters and formatters. Automating those (in this case by defaulting to the expected outcome) reduces friction on basically every operation anyone might do in a project, in any context.

Through the lens of kindness, it benefits you as well as your team… and ultimately everyone else downstream, since you’re all not wasting time and cognitive load on trivially preventable mistakes.

by eyelidlessness

6/18/2026 at 5:37:03 PM

You frequently having to tell people about a global configuration gitignore is an obvious consequence of "My general rule is that in-repo .gitignore should only be used for repo-specific things". It wastes less of everyone's time to just gitignore them in every project.

by Anon1096

6/18/2026 at 7:25:51 PM

This mindset is how you get lots of IDE/dev-env-specific/platform-specific cruft inside of repos instead of pristine repos. It makes both contribution and maintenance difficult over time. While less of an extreme issue as IDE/dev-env-specific/platform-specific hacks/scripts littering the repo, gitignore entries should be generally justifiable, not ever-growing cruft to be added by each developer specific to their situation.

by kodablah

6/19/2026 at 1:19:49 AM

I add .DS_Store to every repo despite also having it ignored globally. Efficiency beats pristine. I don't want to have to ever think about or deal with it at all.

by zarzavat

6/19/2026 at 12:03:44 PM

> Efficiency beats pristine. _I_ don't want [...]

Emphasis mine. This is the exact mindset I'm referring to, and when applied generally to files in the repo, will bite at some point. Even if you're lucky and it's unimportant/internal enough not to bite users, it will bite contributors. Luckily none of us would be discourteous enough to do this while contributing to another's repo.

by kodablah

6/19/2026 at 6:57:49 PM

If it's my repo then I decide which files are tracked and I don't want any .DS_Store files, nor do I think any person in history has ever intended to track a .DS_Store file.

In a perfect world everyone would add .DS_Store to their global ignore list but since this is not default it necessitates defensive measures.

If you don't add it to .gitignore then I can guarantee at some point a .DS_Store file will be committed to the repo, because the behavior is broken by default.

by zarzavat

6/19/2026 at 1:32:53 AM

but you do think about it when you add it to every repo?

by inigyou

6/19/2026 at 5:27:55 AM

Arguably git should ignore this file by default. 99% of the time it shouldn't be automatically picked up when you want to make a commit.

by charcircuit

6/19/2026 at 7:04:12 AM

It would also be nice if Finder stopped generating .DS_Store files and moved that information to metadata on the directory! They had a great opportunity to fix this when they introduced APFS but alas the blight continues.

by zarzavat

6/19/2026 at 8:09:19 AM

Arguably it does: Every default .gitignore I’ve ever seen has included it.

by solarkraft

6/18/2026 at 10:26:04 PM

Every time I've requested changes to a pull request because the reviewee didn't know the difference between .gitignore and .config/git/ignore, the reviewee appreciated learning about the feature. The person you're replying to also clearly said their reviewees are pleasantly surprised, so it hardly seems like a waste of time. Also consider that it takes almost no effort on our part to point out this feature, no effort for them to learn it because we tell them directly, and it happens at most once per new contributor or hire.

by WCSTombs

6/18/2026 at 8:02:42 PM

I’d really only like my projects to talk about things relevant to the project, instead of having to think about the fact that you might be using Qt Creator.

by saagarjha

6/18/2026 at 9:17:37 PM

Eh. It's a tool, not a document. It should contain things that help development.

by fluoridation

6/18/2026 at 6:51:13 PM

Fair, but it depends how uniform the culture is around a particular project. Is it haskell and everyone is using emacs? Sure, include those. But trying to chase the requirements of half a dozen different editors is silly.

by mikepurvis

6/18/2026 at 7:14:52 PM

That's the thing though, you don't need to do that. Whoever is using whatever editor can do it, so the effort is distributed to whoever cares to contribute.

There is no meaningful penalty for it to be not up-to-date. There is only a benefit for people who come in when it's already configured, as they don't need to configure anything anymore.

(I say that but I'm using a global ignore too for eg ai configuration like skills as I like to half-ass them before discarding again)

by ffsm8

6/18/2026 at 8:06:48 PM

The penalty is a long file full of cruft that's effectively impossible to ever clean up.

by antonvs

6/18/2026 at 6:14:27 PM

I prefer gitignore since it survives dev container rebuilds.

I can set a creation script or volume to restore/persist configs if I must avoid gitignore. However, that's an extra script or devcontainer mounts config over a gitignore line.

by 8cvor6j844qw_d6

6/18/2026 at 6:36:20 PM

In my opinion (which might not be shared by everyone) this is a you problem. Developers in the team not using decontainers should not have to worry about your environment. ide/local-env stuff should be ignored in the users git setup, everything that the repo creates (build artifacts, environment files etc) should be in the repo.

by mvanbaak

6/18/2026 at 7:08:43 PM

Interesting case. For the global ignore file, couldn't you just bind-mount that into the container?

by arcanemachiner

6/18/2026 at 7:16:14 PM

> However, that's an extra script or devcontainer mounts config over a gitignore line.

by paulddraper

6/19/2026 at 8:30:16 AM

Well, that's what I get for being an idiot.

by arcanemachiner

6/18/2026 at 7:17:57 PM

That's an interesting case, where you are crossing operating systems.

---

That said, the easier change is still a one/two line bind mount that trying to exhaustively list ignored directories for every IDE or tool under the sun.

by paulddraper

6/19/2026 at 8:37:46 AM

Or if your editor is happy to store them in a subfolder that is useful. I use Sublime with the AutoProjects extension and it puts .sublime-project snd .sublime-workspace under a .sublime folder that I can have a .gitignore * underneath.

by mjmas

6/19/2026 at 4:11:35 PM

I'd rather have a pristine repo (no .ds_store/.idea/etc) than a pristine .gitignore file.

by kortex

6/19/2026 at 4:36:33 PM

Well you still ignore those things, just not with a committed .gitignore. Now your repo and your gitignore are pristine

by superb_dev

6/18/2026 at 7:23:11 PM

Do you not see the conflict between seeing the same incorrect behaviour again and again, and having a firm rule that expressly forbids the easiest fix to that behaviour?

by mvdtnz

6/18/2026 at 10:25:36 PM

I am getting the impression that people both see and enjoy the conflict. :-/

by dofm

6/18/2026 at 7:15:20 PM

.DS_Store

by paulddraper

6/19/2026 at 5:58:43 AM

My computer doesn’t make .DS_Store files. If yours does, it’s your responsibility to not litter the codebase with them.

Corollary: My computer does make other kinds of files, and you’d never know it.

by aendruk

6/19/2026 at 6:01:01 AM

I agree.

by paulddraper

6/19/2026 at 9:32:42 AM

I have a habit of writing myself notes in various .txt files, and then not cleaning them up often enough so they end up cluttering my `git status` view. I ended up with a solution not mentioned in the article: create a `scratch` directory, and a `scratch/.gitignore` file containing just one line: `*`. This makes Git ignore everything in the scratch directory, including that same .gitignore file — so I never accidentally check it into Git, and don't end up pushing my personal .gitignore settings onto my coworkers.

Of course, I could have used .git/info/exclude for that, and not risked accidentally adding my `scratch` directory with `git add -A` or something. So I (re-)learned something (which I'd known about but forgotten) today.

But as a reminder to anyone else who had forgotten this: .gitignore files are processed throughout the repo, not just at the top level. You can sprinkle them throughout the repo structure for finer-grained control, which may come in handy in some circumstances.

by rmunn

6/19/2026 at 6:00:53 PM

There's also the global gitignore configuration (core.excludesfile=~/.gitignore_global), which for me contains things like: *.swp, .DS_Store, scratch, etc.

by ivan888

6/18/2026 at 2:30:16 PM

~/.config/git/ignore and ~/.config/git/config is the proper place for your global git config and ignore instead of creating a ~/.gitignore_global and changing the config. IMO.

my dotfiles are a lot smaller at the root level taking advantage of the ~/.config/ for a lot more things.

the git exclude isn't used as much because it doesn't get committed to the repository so you'd have to recreate it each time you wanted to use it. that doesn't mean they're bad just why they are not used.

by hk1337

6/18/2026 at 2:42:10 PM

As a bonus, you can (should?) version control your `~/.config` dir to enable future revisions and sharing.

by b40d-48b2-979e

6/19/2026 at 4:24:32 PM

check out gnu stow for this! i place my config files in ~/dots, mirroring the structure as if it were my home directory, and gnu stow can symlink everything to my home directory for me. then, only the dots directory is checked into version control.

i find this better than putting all of ~/.config in git, since i don't necessarily want everything there to be version controlled.

video i learned this from: https://youtu.be/y6XCebnB9gs

gnu stow: https://www.gnu.org/software/stow/

by nsyne

6/18/2026 at 10:11:43 PM

You may need to have certain directories be excluded depending on the programs you use. For example, the default Chrome profile location is within ~/.config, which includes cache data that can be multiple gigabytes in size.

by mroche

6/19/2026 at 12:53:26 AM

Ouch. It doesn't respect `$XDG_CACHE_HOME`?

by b40d-48b2-979e

6/19/2026 at 3:14:14 AM

That's what .gitignore is for ;)

by Ferret7446

6/18/2026 at 2:57:00 PM

Absolutely. On that subject, I prefer the Atlassian method for storing dotfiles in git but sometimes I feel like it's Mootools vs jQuery all over again.

by hk1337

6/18/2026 at 9:38:22 PM

Or use ~/.cvsignore for all the other things which use that same file.

by coryrc

6/18/2026 at 2:34:27 PM

Not sure where I picked up this, but I’ve added this to my global Git ignore:

    attic
That way you can just create an attic directory in any project where you can keep random stuff that should never be committed. I’ve yet to find a repo which actually has such a directory checker in.

by judofyr

6/18/2026 at 10:05:44 PM

You can also sort of invert this, but you have to do it on a case by case basis.

Let's say you have a directory like attic; you can put inside a `attic/.gitignore`:

  /**
& then that directory (and anything in it) is ignored, including the ignore file itself.

I usually name my version of this directory the single character U+1F4A9, which HN refuses to permit me to put in a comment ;)

by deathanatos

6/19/2026 at 12:36:53 PM

Oh this is nice! I'll have an attic folder from now on

by oveja

6/18/2026 at 4:32:22 PM

Mine is

    aux
and I hide it by putting a .gitignore in it that just contains am asterisk (*), nothing else, that way it ignores itself and anything in it.

by weinzierl

6/18/2026 at 6:33:15 PM

Does Windows still go crazy when making an “aux” or “con” directory or has this been patched?

by trinix912

6/18/2026 at 9:19:56 PM

It's never going to be patched because it's not considered a bug.

by fluoridation

6/18/2026 at 5:27:22 PM

Genius idea.

by metadat

6/18/2026 at 6:20:21 PM

The next Elon musk.

by addedGone

6/18/2026 at 2:38:17 PM

I do this too! But I call it `.local`

by williamjackson

6/18/2026 at 4:00:09 PM

I have a new-repository script that creates a .local directory and puts a .gitignore with just `*` in it.

by zahlman

6/18/2026 at 4:44:15 PM

Doesn't git automatically exclude all files starting with a dot?

by bflesch

6/19/2026 at 12:32:39 AM

Hey do you have a GitHub I can look at?

by groundcontr01

6/19/2026 at 11:04:02 AM

I have nothing of value ;D

by bflesch

6/18/2026 at 5:07:27 PM

No

by micael_dias

6/18/2026 at 7:46:49 PM

mine's `scratch/`

hasn't tripped me up (yet)

by thewisenerd

6/18/2026 at 4:46:56 PM

Re: per-user ignores:

> For example, if you’re on macOS, adding .DS_Store here would be ideal.

As long as every Mac user on your project does. If you have more than one, it may be better off taken out of everyone's hands.

by dofm

6/18/2026 at 11:37:20 PM

I couldn't say for sure where it came from, but both my Macs (one with Ventura, one with Sequoia) have a ~/.gitignore_global file with an entry for .DS_Store, plus whatever stuff in the global git config makes git ignore stuff mentioned in that file.

This file on my newer Mac is dated 2 days before I ordered it, and I don't remember setting any of this up, so I assume it came like this out of the box. I can't remember the dates for my older Mac, but I assume it's the same thing - and the macOS versions suggest that the default setup might have been like this for a while now.

So, perhaps the days of having to add .DS_Store/ to your .gitignore file are over!

by tom_

6/19/2026 at 12:02:36 AM

Perhaps that is the norm for the command line tools now anyway, yes.

by dofm

6/18/2026 at 7:25:27 PM

That's a very particular way to frame the few vs the many. If a single macOS user works on ten different projects, should all ten projects add that line, or may things be better off taken out of each project's hands and on that single user?

by tremon

6/18/2026 at 10:10:40 PM

> If a single macOS user works on ten different projects, should all ten projects add that line,

Not only do people think that, they also think that every pet tool that every pet user might decide to use should also end up cluttering up .gitignores for every project on earth. Worse, these people have created whole templates for this, so they can start a new project with ignores for dozens of tools they don't even use. 9 out of 10 times, this includes a broken ignore for Vim swap files.

I think these people are crazy, and like you suggest, tooling that is particular to you should go in the user's ignore, and tooling particular to the project should go into the repo's ignore.

by deathanatos

6/18/2026 at 10:20:57 PM

I mean I was just making a quick pragmatic suggestion about a labour-saving change that might be more sensible in practice, given that, rather than being a "pet tool" from a "pet user", it's a default side-effect of a platform that is modestly common in the hands of open source developers (as well as a common accidental side-effect from handling tarballs supplied by Mac users to non-Mac users).

But I wouldn't want to deny anyone an opportunity to regularly rehash a narrow tribal complaint in the comments on a pull request. Yeesh.

by dofm

6/19/2026 at 1:07:05 PM

> If you have more than one

They already answered your situation in their post.

by hennell

6/18/2026 at 7:48:27 PM

I mean sure, if you're this worried about ten bytes and prefer instead to spend time endlessly lecturing new Mac-based submitters about the additional overhead of supporting Mac-based submitters.

by dofm

6/18/2026 at 8:03:56 PM

As a Mac user, you should tell them how to do a better job.

by saagarjha

6/18/2026 at 9:57:06 PM

This level of tribal antagonism over ten quite commonplace bytes is IMO entirely overcooked, but it is an excellent demonstration of

https://en.wikipedia.org/wiki/Narcissism_of_small_difference...

Me, I am pragmatic. I have set this in my local config and I've added it to my repos to be certain. Because it's ten bytes.

by dofm

6/19/2026 at 5:10:40 AM

To be fair, if I submit changes and don’t notice I added .vscode / .idea / my_notes.txt / .DS_Store / .swp then it was a sloppy job and I shouldn’t expect the project to adapt to ignore every possible garbage file so that I can continue carelessly “git add .”-ing

I assume that’s why some open source maintainers don’t bother either - if you haven’t even looked at your diff before submitting then why should they?

by gcarvalho

6/19/2026 at 4:32:03 AM

No I just think they should be aware of what their OS is doing

by saagarjha

6/19/2026 at 11:50:58 AM

Placing various artifacts (eg. build artifacts) inside the source tree always seemed like a historical mistake to me. It leads to various accidents such as people checking in their credentials and accidentally bundling such files in source distributions, for example. These consequences are real.

Debian build tooling places build artifacts in the parent directory on the assumption that this is acceptable, but it then surprises people since it's not the norm anywhere else.

Perhaps this ship has sailed. But I think it's worth pointing out that if you have an option, don't design things that place things inside the source tree if you can avoid it.

by rlpb

6/18/2026 at 3:36:26 PM

One point of clarification: with git, "global" means per-user, not "machine-wide. (I never understood why "--global" wasn't better named, maybe "--user".) That's why these pathnames are in a user's home (the "~" means the current user's home directory).

Machine-wide configuration is called "system" in git, and generally lives under "/etc".

by wpollock

6/18/2026 at 2:07:36 PM

I use the ever living hell out of .git/info/exclude. Works great for scripts/Makefiles I only want locally and collaborators wouldn’t care about or be able to use.

by bryancoxwell

6/18/2026 at 2:30:04 PM

Interested in examples of the types of scripts others collaborators wouldn't be able to use? Like scripts for PR workflows?

by RSHEPP

6/18/2026 at 2:33:58 PM

Usually when I'm working in one part of the codebase and I have sample data or something at a specific path on my local machine and Im testing the same thing over and over again will I make a Makefile or something and info/exclude it to help me keep focused. That's one way I use it.

by junon

6/19/2026 at 4:21:48 PM

I use git worktrees pretty heavily in my own workflows (I worked like an AI agent before AI agents made worktrees cool). I like to track my ephemera/utility scripts in git, so what I do is keep a private ephemera repo for those, and then use `git worktree add` from the collaborative repo to check out the branch I'm working on there into a subdirectory of my ephemera repo.

  git-home/
    company-project/ <-- git repo with main checked out
    ephemera/ <-- my private repo
      my-data-script.py
      work/ <-- gitignored
        company-project-feature-X/ <-- worktree on feature-X branch
        company-project-feature-Y/ <-- worktree on feature-Y branch
This way, too, I can easily use the same ephemera scripts across multiple branches, or even multiple repos, concurrently.

by tomjakubowski

6/20/2026 at 8:31:33 AM

Oh this is really clever, I'll have to try this. Thank you :)

by junon

6/18/2026 at 2:58:29 PM

Yeah this is pretty much it.

by bryancoxwell

6/18/2026 at 3:52:29 PM

For quite a while, I've have had a shell fcn that will take all the untracked files listed in a git status, and push them to .git/info/exclude. Generally applied after an add+commit of everything I do want to go generally into the repo.

by digikata

6/18/2026 at 10:19:06 PM

Relatedly, some aliases I have in place.

  assume = update-index --assume-unchanged
  unassume = update-index --no-assume-unchanged
  assumed = "!git ls-files -v | grep ^h | cut -c 3-"
  unassumeall = "!git assumed | xargs git update-index --no-assume-unchanged"
  assumeall = "!git st -s | awk {'print $2'} | xargs git assume"

by elyobo

6/18/2026 at 7:31:04 PM

Wow! How did I not know this? I am a professional software dev for 20 years… and only ever used .gitignore !

I just realized that I never even „asked“ myself if there might exist a better way than to clutter .gitignore with all kinds of specific excluded only relevant to me. I just accepted the world as it appeared to me…

And Today, it got s little bit better :-)

by lmf4lol

6/18/2026 at 1:55:54 PM

This is just a very low-effort regurgitation of this: https://git-scm.com/docs/gitignore

by Hendrikto

6/18/2026 at 3:45:12 PM

Submit that link to Hacker News, and see how far it gets!

by axus

6/18/2026 at 2:00:51 PM

Hey, come on now - they added 'check-ignore' which is good complementary advice.

by jagged-chisel

6/18/2026 at 2:17:45 PM

You made my day. Everything is said and explained there.

Ok, sometimes a more vivid and visually explanatory style would help, but here still Google is your friend for individual concepts.

One of the best resources there is. git is a hell of a tool. It looks simple but is so beautifully versatile without being complex or not deductive.

by _the_inflator

6/18/2026 at 2:25:47 PM

"Google is your friend for individual concepts."

Asking aLlm is the new google

by y2244

6/18/2026 at 2:31:13 PM 

    git is a hell of a tool. It looks simple but is so beautifully versatile without being complex

    without being complex
Uh, what?

by b40d-48b2-979e

6/18/2026 at 2:32:39 PM

What part of

   Enumerating objects: 15, done.
   Counting objects: 100% (15/15), done.
   Delta compression using up to 10 threads
   Compressing objects: 100% (8/8), done.
   Writing objects: 100% (8/8), 1.43 KiB | 1.43 MiB/s, done.
   Total 8 (delta 7), reused 0 (delta 0), pack-reused 0 (from 0)
   remote: Resolving deltas: 100% (7/7), completed with 7 local objects.
don't you understand?!

by rafram

6/18/2026 at 10:27:45 PM

One of the things I find funniest about git is that it is so exasperating that there is a comedy tool that generates fake git man pages that are worryingly convincing.

https://git-man-page-generator.lokaltog.net/

And each time someone quotes one there is a chance that an LLM will be trained on it.

by dofm

6/19/2026 at 12:53:54 PM

I didn't know about this. This is brilliant. Sorry, I probably just polluted the LLMs a bit more.

by Intermernet

6/18/2026 at 3:29:34 PM

Well, since I know what a delta is, and I know what an object is, I understand all of it.

by onraglanroad

6/18/2026 at 4:41:58 PM

Congratulations!

by rafram

6/18/2026 at 8:32:26 PM

Learn what those two things are and you can join me in celebration!

by onraglanroad

6/19/2026 at 3:41:13 AM

In fact, I understand every part of it.

I just can't ever be confident the command I write will do the thing I expect it to...

by marcosdumay

6/18/2026 at 10:03:48 PM

There is also

  git update-index --[no]-skip-worktree
for files that are already tracked. This can be useful for some local experimentation... it's just a bit annoying to use because it's not really surfaced anywhere by git (kinda). You need to remember that you set it; otherwise other operations like checkouts may be blocked.

by leleat

6/19/2026 at 5:41:43 AM

This is what I use for making changes to local settings.json. Works nicely.

by oezi

6/19/2026 at 1:24:48 AM

One trick I’ve used is creating a folder and then adding a .gitignore inside it with *. Then nothing in that folder gets tracked, without needing to add anything to the public gitignore. Didn’t know about .git/config though!

by supermdguy

6/19/2026 at 8:17:21 AM

Yeah it's in the document but there are no examples on it.

by linhns

6/18/2026 at 3:07:40 PM

I knew about .git/info/exclude and ~/.config/git/ignore but not about git-check-ignore(1). Neat!

by jeremyscanvic

6/19/2026 at 7:59:43 AM

Wow, how did I not know about the exclude file? I've had this need so many times - working on a shared repo where I want to ignore some files locally.

by stevage

6/19/2026 at 3:57:11 AM 

    you may have a personal notes.txt file in a repository that you don’t want to check into git but you also don’t want to add to .gitignore because it’s unique to your workflow. 

    The exclude file lives in the .git directory of every Git repository but changes to it are not checked into Git
Wtf. I've always wanted this, and it was right there.

by adamgordonbell

6/19/2026 at 7:45:06 AM

> Wtf. I've always wanted this, and it was right there.

Haha, same! I was literally looking for this feature last week without realising.

What could be more git- the problem is rarely that it can't do something, but the ergonomics of discovering how to make it work correctly.

by benrutter

6/19/2026 at 2:53:43 AM

>~/.config/git/ignore

This never be considered as a solution. It only works on that PC, when working with a team, this approach is wrong in so many levels.

I host my own Forgejo server/repos, it is just me but .gitignore just makes more sense. It is on the root of the project, and I only have one file to manage. No matter that PC/device I am using, they are automatically covered.

by h4kunamata

6/19/2026 at 2:58:12 AM

Idk, I can imagine a specific weird usecase. I use IntelliJ. My coworkers don't. They don't want my .idea folder in git. (You're probably thinking "ok, yep, gitignore!" And you're right except my boss ideologically does not want any *hint* of what IDE you use in the repo. Including in the gitignore.

So each person putting .vscode or .idea in their local config's ignore actually makes sense. (Relative to the nonsensical parent requirement... of course).

by atomicnumber3

6/19/2026 at 3:12:29 AM

That sounds like a you problem for not syncing your dotfiles across devices

by Ferret7446

6/18/2026 at 10:49:52 PM

Here's how I use the excludes file to set a different config for a project directory containing multiple repos:

https://laszlo.nu/blog/project-level-git-config.html

by andrelaszlo

6/19/2026 at 1:53:35 PM

I *literally* cannot read that yellow text on the white background. I even tried changing the brightness to almost 0, but there is just not enough contrast.

by sgc

6/19/2026 at 5:46:51 PM

Oh no, I forgot to test light mode. Thanks for letting me know!

I'll fix it as soon as I'm in front of a computer. Happy Midsummer!

by andrelaszlo

6/19/2026 at 12:52:21 PM

I love these types of threads the most. I learn so much.

by ramijames

6/19/2026 at 4:00:23 PM

My first and hopefully only clash with the global ignore file was debugging why a project worked differently between machines. There was a global ignore on the machine I was working on (that I didn't place) that "smartly" tried to exclude "irrelevant" code / project files regardless of project.

I see version control somewhat similarly as I see traffic laws. Sure, they could work in entirely different ways, Germans like their autobahns, but breaks to the norm in an otherwise planar field are rarely arguable for.

by maxlin

6/19/2026 at 1:56:39 AM

Nice, I didn't know the other options besides .gitignore

by dalton_zk

6/19/2026 at 3:01:42 PM

something new i learned today, thanks!

by codensolder

6/18/2026 at 2:52:07 PM

I still like using gitignore very much

by bitvvip

6/18/2026 at 6:53:55 PM

git is so incredible, it never ceases to amaze me, what a timeless piece of software

by hmokiguess

6/18/2026 at 3:41:12 PM

Magit has good support for these other methods. You press <i> and then select if you want the ignore to be shared (.gitignore) or private (.git/info/exclude).

by globular-toast

6/18/2026 at 11:48:55 PM

Magit introduced me to them in the first place. :-D

by juxtapose

6/19/2026 at 12:59:07 AM

Point of pedantry:

  > The ignore file lives in your machine’s home directory in ~/.config/git/ignore. Whatever filenames are added to this file are ignored globally at a machine-level.
The wording here is slightly wrong: ~/.config/git/ignore will ignore files per-user on the machine, not "at a machine level". And it's not "your machine's home directory", it's your user's home directory on that machine. Any other users on the same machine will not see this. Git calls this "global", as in "global for the user".

Git config does also have a --system option which modifies the system-level config file, /etc/gitignore. You could probably ignore stuff at the system/machine level (hint: you don't want to), with this. I'd do something like:

  $ sudo git config --system core.excludesFile /etc/gitignore
  $ sudo touch /etc/gitignore
Note however that user config will override this, so any user who has a core.excludesFile setting will not also look at your system level excludes file. Which is a pretty big caveat.

by antisol

6/19/2026 at 2:19:49 PM

Why would you expect something in your home directory to affect other users?

by smw

6/20/2026 at 1:06:32 AM

Why would you ask me that? I'm not the one who called it "your machine's home directory"

by antisol

6/18/2026 at 5:13:37 PM

these are great for ignoring files by name, but you often want to ignore binary files or other files by type.

Set a global hooks dir, and then block binary files in pre-commit by using file or checking the git index

   git config --global core.hooksPath ~/.config/git/hooks
Or block large changes, because binary mods are often larger than a real diff.

by tonymet

6/19/2026 at 2:11:02 AM

but dont forget dockerignore if you use docker

by yieldcrv

6/19/2026 at 7:53:12 PM

another way is to use shortcuts

by pacman1337

6/18/2026 at 6:10:32 PM

another useful snippet

    [includeIf "hasconfig:remote.*.url:git@git.company.com:*/**"]
    path = /home/dir/per/company/config
allows for remote specific configs, overriding say email or other required options depending on where you send contributions - without having to have per repo config

works for dir too

    [includeIf "gitdir:/home/user/src/work1/"]
Git is REAL bitch about exact syntax here; the first snippet won't work with just :*, it needs :/* ; the second won't work without trailing slash

by PunchyHamster

6/19/2026 at 2:28:09 PM

[flagged]

by shinobi-apps

6/18/2026 at 9:58:34 PM

[flagged]

by codymisc

6/20/2026 at 1:57:36 AM

[dead]

by p1024k

6/18/2026 at 10:47:53 PM

[dead]

by arikrahman

6/18/2026 at 3:54:56 PM

Not really news. I worked with dozens of developers who have managed to ignore files in Git.

by uptown

6/18/2026 at 3:16:54 PM

Exclude sounds like a recipe for sadness.

by barbazoo