Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

nelson.cloud

Post reply on HN
Print view View original

141–150 of 188 posts

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

#141

Post by lloydatkinson »

hungryhobbit wrote: post #61

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.

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

#142

Post by StarlaAtNight »

po1nt wrote: post #67
clates wrote: 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.

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

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

#144

Post by rlpb »

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.

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

#145

Post by rlpb »

hungryhobbit wrote: post #61

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…

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

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

#146

Post by kodablah »

zarzavat wrote: post #101
kodablah wrote: post #55

Earlier quoted context omitted.

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

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.

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

#147

Post by oveja »

deathanatos wrote: post #76
judofyr wrote: post #12

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.

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

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

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

#149

Post by Intermernet »

dofm wrote: post #84
rafram wrote: post #10

Earlier quoted context omitted.

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?!

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.

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

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

#150

Post by hennell »

tremon wrote: post #54
dofm wrote: post #32

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.

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?

> If you have more than one

They already answered your situation in their post.

Post reply on HN