Live data from Hacker News

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

nelson.cloud

131–140 of 188 posts

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

#131

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…

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

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

#132
post #123
post #120

Earlier quoted context omitted.

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

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.

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

#133

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.

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

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

#135

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.

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

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

#136

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!

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

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

#137

Earlier quoted context omitted.

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

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

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

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

#138

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…

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.

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

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

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.

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

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

Post reply on HN