alt Hacker NewsFun 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).
With `.gitattributes` in the root of your project, you can just add a line:
`package-lock.json -diff`
Now, that file will still get staged/committed (which you want) ... but when you `git diff` you won't see the massive amounts of pointless diff in that file.
Replies
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!
package-lock.json shows all your transitive dependencies, package.json just shows your direct dependencies. It is simply not true that the latter is "the real human-readable version". They serve different purposes and it is dangerous to say you can always ignore the diff in your lock 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).
You should 100% track package-lock.json, and I'll go a step further and say you should most likely track node_modules too.
Better: set up a git diff driver so you see the semantic changes, not line-by-line changes.
Sounds like a powerful feature for subverting code review…
as someone who deals with dep upgrades and forensics when trying to figure out a bug I would get _so mad_ if `git diff` didn't show the diffs to lock files.
I get what you're saying about it being line noise but when you need it you need it!
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.
> 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.