5 ms·

> 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

• po1nt 4mo ago
  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.
  • gpvos 4mo ago
    DX = ? Developer experience maybe?
    • sisve 4mo ago
      Yes
  • nine_k 4mo ago
    The point is that it should not be massive.
    • scrame 4mo ago
      Tell that to the NPM folks.
  • jeromegv 4mo ago
    But it's not always massive, it's a good practice to see what the diff is and ensure there is no weird dependency (aka supply chain attack) showing up in there.
    • po1nt 4mo ago
      In my opinion you have no chance of identifying supply chain attack like this. It's not like you will see "evil-package": "*" in there. Supply chain attacks happen by appending obfuscated code deep into dependency no one knew you had in the first place.
  • selcuka 4mo ago
    > you just want to see that the file changed I check the diff for uv.lock (Python counterpart of package-lock.json) every time I merge a PR. It is important to know which direct or transient dependencies have been updated. We don't blindly bump all dependencies to the latest versions (you shouldn't either).
    • panzi 4mo ago
      Python packages aren't quite so insane on transitive dependencies. The diff of package-lock.json can be novel length.
      • gjvc 4mo ago
        write your requirement.txt files via pipdeptree --freeze to see this clearly
        • selcuka 3mo ago
          FYI the uv equivalent is uv pip tree
          • gjvc 3mo ago
            not interested, really
    • Groxx 4mo ago
      same - I check the changelog for every major (== minor if v0) and some minor version changes in most of my projects, including at work. I've caught quite a lot of would-have-broken-something changes, and opportunities for fixes/optimizations/etc by doing so. and sometimes they mention fixing a bug we didn't know we had, so we learned about it early before it corrupted too much data.
      • Maxion 4mo ago
        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.
  • sublinear 4mo ago
    It's a CLI. DX is not the only concern. What about scripts that expect the default git behavior? You could argue "those scripts are dumb then! outta my way!", but then you shouldn't be using a CLI for whatever it is you're trying to do. If you insist, you can just grep or use the --stat option. We already know the git CLI has plenty of antifeatures like this. It is up to the devs how they want to proceed, but it doesn't change the fact that hiding things is a footgun.
    • po1nt 4mo ago
      You can suppress the git attribute system if you need default settings. I wouldn't call it "antifeature" but customizability as git was always supposed to be used with CLI, this is just a way to make output less verbose.
  • palata 4mo ago
    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.
    • Filligree 4mo ago
      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.
      • palata 4mo ago
        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.
  • StarlaAtNight 4mo ago
    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
  • jitix 4mo ago
    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.
• ChrisRR 4mo ago
  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
• kortex 4mo ago
  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.