Live data from Hacker News

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

nelson.cloud

121–130 of 188 posts

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

#121

Earlier quoted context omitted.

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.

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

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.

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

#122
post #75

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.

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

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

#123
post #120
post #110

Earlier quoted context omitted.

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.

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.

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

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

#124
post #91
post #67

Earlier quoted context omitted.

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.

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

[deleted]

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

#125

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 p…

.DS_Store

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.

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

#126

Earlier quoted context omitted.

.DS_Store

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.

I agree.

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

#128
post #67

Earlier quoted context omitted.

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.

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.

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.

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

#129

Earlier quoted context omitted.

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

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.

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.

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

#130
post #67

Earlier quoted context omitted.

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.

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 does…

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.
Post reply on HN