Live data from Hacker News

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

nelson.cloud

151–160 of 188 posts

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

#151
post #66

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…

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

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

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

#152

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

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.

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

#153

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…

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

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

#154
post #139
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.

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.

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.

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

#156

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…

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.

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.

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

#158
post #66

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…

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

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.

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

#159

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…

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.

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.

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

#160
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.

Post reply on HN