Live data from Hacker News

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

nelson.cloud

171–180 of 188 posts

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

#171

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.

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

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.

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

#172
post #67
post #66

Earlier quoted context omitted.

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

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.

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

#174

Earlier quoted context omitted.

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!

eg. config.json merge=ours

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

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

#175

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.

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?

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

#176

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…

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

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

#177

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…

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

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

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

#178

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…

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

[dead]

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

#179
post #139

Earlier quoted context omitted.

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.

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.

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

#180
post #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?

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