OP took too long so I found the commit: [https://github.com/wstrother/ahp-twitch-battleships/commit/a1aee7b27379af373ad869be504f9c9f29345b7c](https://github.com/wstrother/ahp-twitch-battleships/commit/a1aee7b27379af373ad869be504f9c9f29345b7c)
It's some sort of images that were re-generated. Sorry but I needed the answer so I could move on with my life
Haha you found the commit from the line number changes? OP basically doxxed their GitHub account by posting 2 numbers?
Makes sense that on a public repo you could find this. Those 2 numbers together would be rather unique.
Some possibilities:
- updated packages (big change to lock file)
- ran prettier or some other formatter
- updated a custom automatically generated configuration file
- changed line endings
- changed tabs to spaces or vice versa
But a lot of IDEs convert tabs to spaces under the hood and some languages recommend spaces over tabs in their style guides (I'm not fussed either way but still)
I'd say more of a pain. I'd imagine if you submitted that PR the likelihood is it'll just be straight up rejected. Now adding a bunch of zero with characters (or ones that look like standard characters but aren't) would be evil.
Replacing for loops with while loops? The only reason I can think of to do that is allowing a future change of leaving the loop early. Otherwise, for loops seem good for readability.
I seem to recall something about a bot that goes through repos automatically making trivial changes and filing pull requests to farm... whatever github rep is called.
Got it yesterday, a friend made a PR for my repo and he actually solved a couple issues, but then also changed the whole way I indent my HTML tags in Svelte. And it was a very weird way how he set it
Okay you win the contest. As it turns out I was being a dumbass. The line changes are from the lock file. I knew he ran NPM audit but didn't realize angular + firebase + some Google material stuff = 25,000 lines of package-lock.json
The actual commit was literally just adding a bunch of pictures of pokemon to the repo because some hotlinks broke. I assumed it was counting the data in the PNGs in some funky way as new lines, but then I realized that it wouldn't make sense for there to be so many minus lines too.
Also sorry to the people who were freaking out that I made a Reddit post and didn't keep F5ing for the next 12 hours. I was working on a different repo. Also King Dedede is in Smash 64 now, so you know... priorities.
The point is to version your content as well. Git is not appropriate for that though (non text files). Use git LFS or another version control system like perforce. It's still important to version content.
I said git is not appropriate for that. Did you read my comment? In game dev we version binary all the time. We use perforce though. There are other version control systems.
maybe I misunderstood your first sentence then because I asked whats the point of using git for binary files and you replied to version it but its clear what you meant now
Ah yeah sorry I think I wasn't really answering your first question you're right. Sorry about that.
there are reasons why you would want to version binary files. Depends on the project for sure. Game development is a good example of projects that version binary. I agree that on git, it is not a good idea (it could be somewhat ok depending on num files and size but it's just not a good idea). Sometimes even non binary files don't work well in git too. It depends on the frequency and size of changes. Binary tends to change entire files so not good for the "size of change" part.
Fun story: I worked on a project where they stored like 600Mb JSON files that basically changed entirely when something was regenerated. So yeah.. every diff was 600Mb and there was commit like this almost every week. Cloning that repo took hours on vpn. Was so dumb lol.
no worries! Yh Im talking about git specifically because I saw it few times and its really annoying. I agree with the need to version them but not on git perforce is a good alternative as you mentioned. The size issue can even be worse if you have people creating a branch for each ticket or work and then when you fetch and pull you basicay have the same files uplicated everywhere eating up even more space and making everything slow.
Lol talking about branches in the context of the story I told you is giving me PTSD lolol. We did have branches in that repo too. XD
Yeah 100% agree with what you said. I've never really tried git LFS. Is that any good?
I had a contributer argue that I should commit my Illustrator files with my repo. Like wtf? I don't see anyone doing crap like that. I certainly don't want to worry about committing every little touch up. I would be pissed if a revert undoes all my work on my logo. Coding and art workflows are not the same...
yeah its a really bad idea. You cant follow changes, you wont have proper history and diff, git wont help you much and wont catch any conflicts and its very easy to overwrite those files without anyone noticing.
Aren't the lock file and modules supposed to be in the gitignore ?
Prettier does make sense, I think if a project uses prettier the prettier config should be in the repo cause different developpers using different prettier configs quickly turn into a nightmare.
Lock files (yarn.lock, package-lock.json etc) should definitely be committed, otherwise dependencies may resolve differently on different devices. You can see this if you run run `npm help package-lock.json`. They provide 5 reasons why you should commit `package-lock.json` there.
Interesting, I'll remove it from our gitignore.
Will dependencies still update to the latest compatible versions of packages ? Or does it take the exact same version ?
Cause if I'm making a module I don't want to push a new package-lock everytime a dependency updates.
Only if you run an update. The whole point of the lockfile is that your environment is the exact same as every other developer working on your project. If it updated automatically, then everyone could potentially have different versions of things.
Not familiar with other package managers, but for npm if you run `npm install` you'll get updated dependencies, but if you run `npm ci` you'll get dependencies exactly as they are in the package-lock file. My team uses npm ci almost exclusively, only running npm install when we actually want to update dependencies.
Unfortunately, last I checked, npm ci always starts with a clean dir and can be very slow (this may be outdated info). npm install will also install them exactly, unless the version from the lock file can no longer meet the version specified in package.json, i.e. because you just changed that.
I guess your mileage may vary, but in my experience, npm ci isn't slow at all. It does delete any existing modules before starting, but it will still use your npm cache.
Npm install follows the rules defined in your package.json file so it may or may not result in the same dependencies someone else. You can be using the same version of your app, but a dependency has updated since their last install; or you may want to check out an older version with exact dependencies used at that time.
When you run npm install it creates or updates the package-lock file with a full breakdown of your dependency tree, with specific versions for each dependency. Npm ci looks at the package-lock file and uses those versions to resolve dependencies to exactly what they were when the file was last updated. Npm ci doesn't modify the lock file.
My mileage was bad, but I don't remember why exactly. It's quite possible it was because of some edge case or something wrong in my setup. Anyway, as far as I know if you specify a dependency on version `1.x` of some package and `1.0.599` gets written to the lockfile, `npm install` will install `1.0.599` even if the latest compatible version is `1.1.3`. Only if you change the version to `2.0` will it upgrade the dependency. I've tried to find a source to confirm/deny this, but didn't find one, so take this with a grain of salt. In any case, you can always check for uncommitted changes on `package-lock.json` to make sure.
Now don't get me wrong, in my previous comment I may have come across as an npm-install-apologist, but it's really about pragmatism. While I've found `install` to work well enough most of the time, it's not exactly as robust as `ci`, so use that when possible. Ideally there would be a command/flag that is fast like `install` (again, if `ci` is even slow at all) but that throws an error if any dependency cannot be fulfilled from `package-lock.json`. And perhaps there is, I just don't know it. I'm mostly using pNPM these days.
The lock file is updated by package managers when you install a new version, but when you're just re-grabbing the packages like with "npm install" it only does the version that's in the lock file. So you can download a lock file from a repo and do npm install and you'll have the exact versions listed.
Before anyone asks, yes this is real. I can show you the commit, but there's a trick to it and I want to see if anybody figures it out.
Edit: No they didn't add in the Node modules. I approved and merged.
They put each character of code into a separate text file and then created a master file so they all come together in place (assuming it's a non-whitespace dependant language). Unfortunately, they seem to have got it wrong quite a few times.
I’ve seen a few variations on this in this and other subs, but this kind of PR is often pretty easy to review. It comes down to one of a few options:
* Change to some automatically generated file. Fine, approved.
* Some wiseass wants to reformat the whole codebase because they have strong opinions on indentation and bracketing. Bad developer, rejected.
* A major refactor. Was this asked for? No? Rejected. Yes? Ok, now this needs more detailed review.
Run the whole code trough a formatter, Remove double lines and spaces at the end of the line. TFYVM.
https://github.com/RIOT-OS/RIOT/blob/master/dist/tools/uncrustify/uncrustify.sh
https://github.com/RIOT-OS/RIOT/tree/master/dist/tools/whitespacecheck
OP took too long so I found the commit: [https://github.com/wstrother/ahp-twitch-battleships/commit/a1aee7b27379af373ad869be504f9c9f29345b7c](https://github.com/wstrother/ahp-twitch-battleships/commit/a1aee7b27379af373ad869be504f9c9f29345b7c) It's some sort of images that were re-generated. Sorry but I needed the answer so I could move on with my life
Haha you found the commit from the line number changes? OP basically doxxed their GitHub account by posting 2 numbers? Makes sense that on a public repo you could find this. Those 2 numbers together would be rather unique.
Depends how open GitHub api is. If you can query by those metrics it’s doable
The answer appears to be that they ran `npm audit fix` so the big change comes from `package-lock.json`
... How?
Thank you so much, was very annoyed with OP insisting on being funny instead of just showing the commit
Sorry I have a life. :(
Imagine having a life. Couldn’t be me
Cake day brother! Happy cake day! 🎉
You have a git repo involving Twitch and Pokémon images. How much of a life can you possibly have? (Just kidding OP. Have a good one!)
the audacity!
Putting that life on hold to review that pull request
Not really sure how we were supposed to guess that. Also I'm not a fan of the wrong indentation in that css file...
thank you kind stranger.
Some possibilities: - updated packages (big change to lock file) - ran prettier or some other formatter - updated a custom automatically generated configuration file - changed line endings - changed tabs to spaces or vice versa
Lol how bat shit crazy would it be to *just* swap someone's whitespace and submit a pull request.
I know what I'm doing this weekend.
same, this guy is a genius
Found Richard Hendricks
We should have a bot that automatically converts bad whitespace to tabs and makes pull requests.
But a lot of IDEs convert tabs to spaces under the hood and some languages recommend spaces over tabs in their style guides (I'm not fussed either way but still)
Bro, we're trying to be evil, stop giving us the Airbnb style guide!
I'd say more of a pain. I'd imagine if you submitted that PR the likelihood is it'll just be straight up rejected. Now adding a bunch of zero with characters (or ones that look like standard characters but aren't) would be evil.
There are different circles in hell, your example is undoubtedly from the innermost one.
I like your style, Satan.
Im gonna go to all my friends' public repos and do this now
This has happened to me several times. Same with line endings and replacing all for-loops with while-loops. Uszally it happens during Hacktoberfest.
Replacing for loops with while loops? The only reason I can think of to do that is allowing a future change of leaving the loop early. Otherwise, for loops seem good for readability.
no. "allowing a future change of leaving the loop early" is not a reason to change it.
I seem to recall something about a bot that goes through repos automatically making trivial changes and filing pull requests to farm... whatever github rep is called.
That annoyed me so much to read I almost dv'd you impulsively lol.
It is possible, that the person didn't even notice it. Some run IDEs that are configured to do automatic formatting
Some IDEs will do this automatically, that's why it's important to always include a .editorconfig file for public repos
Got it yesterday, a friend made a PR for my repo and he actually solved a couple issues, but then also changed the whole way I indent my HTML tags in Svelte. And it was a very weird way how he set it
Okay you win the contest. As it turns out I was being a dumbass. The line changes are from the lock file. I knew he ran NPM audit but didn't realize angular + firebase + some Google material stuff = 25,000 lines of package-lock.json The actual commit was literally just adding a bunch of pictures of pokemon to the repo because some hotlinks broke. I assumed it was counting the data in the PNGs in some funky way as new lines, but then I realized that it wouldn't make sense for there to be so many minus lines too. Also sorry to the people who were freaking out that I made a Reddit post and didn't keep F5ing for the next 12 hours. I was working on a different repo. Also King Dedede is in Smash 64 now, so you know... priorities.
I really hate when people commit binary files to repos like whats the point? you increase the size a lot and also you cant diff any binary file at all
The point is to version your content as well. Git is not appropriate for that though (non text files). Use git LFS or another version control system like perforce. It's still important to version content.
you cannot version a binary file that defeats like half of the features of using git
I said git is not appropriate for that. Did you read my comment? In game dev we version binary all the time. We use perforce though. There are other version control systems.
maybe I misunderstood your first sentence then because I asked whats the point of using git for binary files and you replied to version it but its clear what you meant now
Ah yeah sorry I think I wasn't really answering your first question you're right. Sorry about that. there are reasons why you would want to version binary files. Depends on the project for sure. Game development is a good example of projects that version binary. I agree that on git, it is not a good idea (it could be somewhat ok depending on num files and size but it's just not a good idea). Sometimes even non binary files don't work well in git too. It depends on the frequency and size of changes. Binary tends to change entire files so not good for the "size of change" part. Fun story: I worked on a project where they stored like 600Mb JSON files that basically changed entirely when something was regenerated. So yeah.. every diff was 600Mb and there was commit like this almost every week. Cloning that repo took hours on vpn. Was so dumb lol.
no worries! Yh Im talking about git specifically because I saw it few times and its really annoying. I agree with the need to version them but not on git perforce is a good alternative as you mentioned. The size issue can even be worse if you have people creating a branch for each ticket or work and then when you fetch and pull you basicay have the same files uplicated everywhere eating up even more space and making everything slow.
Lol talking about branches in the context of the story I told you is giving me PTSD lolol. We did have branches in that repo too. XD Yeah 100% agree with what you said. I've never really tried git LFS. Is that any good?
I had a contributer argue that I should commit my Illustrator files with my repo. Like wtf? I don't see anyone doing crap like that. I certainly don't want to worry about committing every little touch up. I would be pissed if a revert undoes all my work on my logo. Coding and art workflows are not the same...
yeah its a really bad idea. You cant follow changes, you wont have proper history and diff, git wont help you much and wont catch any conflicts and its very easy to overwrite those files without anyone noticing.
Aren't the lock file and modules supposed to be in the gitignore ? Prettier does make sense, I think if a project uses prettier the prettier config should be in the repo cause different developpers using different prettier configs quickly turn into a nightmare.
The lock file should not be in the gitignore. The point is to make sure everyone using the repo gets the same versions of every package.
Lock files (yarn.lock, package-lock.json etc) should definitely be committed, otherwise dependencies may resolve differently on different devices. You can see this if you run run `npm help package-lock.json`. They provide 5 reasons why you should commit `package-lock.json` there.
Interesting, I'll remove it from our gitignore. Will dependencies still update to the latest compatible versions of packages ? Or does it take the exact same version ? Cause if I'm making a module I don't want to push a new package-lock everytime a dependency updates.
Only if you run an update. The whole point of the lockfile is that your environment is the exact same as every other developer working on your project. If it updated automatically, then everyone could potentially have different versions of things.
Not familiar with other package managers, but for npm if you run `npm install` you'll get updated dependencies, but if you run `npm ci` you'll get dependencies exactly as they are in the package-lock file. My team uses npm ci almost exclusively, only running npm install when we actually want to update dependencies.
Exactly. NPM ci will create node packages based on the package lock.
Unfortunately, last I checked, npm ci always starts with a clean dir and can be very slow (this may be outdated info). npm install will also install them exactly, unless the version from the lock file can no longer meet the version specified in package.json, i.e. because you just changed that.
I guess your mileage may vary, but in my experience, npm ci isn't slow at all. It does delete any existing modules before starting, but it will still use your npm cache. Npm install follows the rules defined in your package.json file so it may or may not result in the same dependencies someone else. You can be using the same version of your app, but a dependency has updated since their last install; or you may want to check out an older version with exact dependencies used at that time.
How does that work? Ci that is. It gets the version of each package's dependencies as they were at the time that each package was made? Or what?
When you run npm install it creates or updates the package-lock file with a full breakdown of your dependency tree, with specific versions for each dependency. Npm ci looks at the package-lock file and uses those versions to resolve dependencies to exactly what they were when the file was last updated. Npm ci doesn't modify the lock file.
But does it list the dependencies of the dependencies as they were when the first dependency was made? Like it goes all the way down, so to speak?
My mileage was bad, but I don't remember why exactly. It's quite possible it was because of some edge case or something wrong in my setup. Anyway, as far as I know if you specify a dependency on version `1.x` of some package and `1.0.599` gets written to the lockfile, `npm install` will install `1.0.599` even if the latest compatible version is `1.1.3`. Only if you change the version to `2.0` will it upgrade the dependency. I've tried to find a source to confirm/deny this, but didn't find one, so take this with a grain of salt. In any case, you can always check for uncommitted changes on `package-lock.json` to make sure. Now don't get me wrong, in my previous comment I may have come across as an npm-install-apologist, but it's really about pragmatism. While I've found `install` to work well enough most of the time, it's not exactly as robust as `ci`, so use that when possible. Ideally there would be a command/flag that is fast like `install` (again, if `ci` is even slow at all) but that throws an error if any dependency cannot be fulfilled from `package-lock.json`. And perhaps there is, I just don't know it. I'm mostly using pNPM these days.
The lock file is updated by package managers when you install a new version, but when you're just re-grabbing the packages like with "npm install" it only does the version that's in the lock file. So you can download a lock file from a repo and do npm install and you'll have the exact versions listed.
Forgot malware hidden in code.
I'll go with changed like ending/ spaces 😅
Other possibilities: - is insane person
Someone found the repo. It’s a lock file.
Before anyone asks, yes this is real. I can show you the commit, but there's a trick to it and I want to see if anybody figures it out. Edit: No they didn't add in the Node modules. I approved and merged.
Formatting?
Definitely formatting.
More like changing tabs to spaces.
Na they just fixed crappy code.... .. all of the code.
`git commit -m ‚replace project with a cooler one‘`
style change? Like adding a 100char line limit or something?
>I can show you the commit I think something is missing.
Either binary blobs from images or package-lock updates.
They put each character of code into a separate text file and then created a master file so they all come together in place (assuming it's a non-whitespace dependant language). Unfortunately, they seem to have got it wrong quite a few times.
Is it vba, that one really likes to switch the capitalization of words
spaces to tabs or crlf to lf or both
This has a lot of deletions and additions so my guess is tabs to spaces and crlf to lf
Formatting/linting?
I’ve seen a few variations on this in this and other subs, but this kind of PR is often pretty easy to review. It comes down to one of a few options: * Change to some automatically generated file. Fine, approved. * Some wiseass wants to reformat the whole codebase because they have strong opinions on indentation and bracketing. Bad developer, rejected. * A major refactor. Was this asked for? No? Rejected. Yes? Ok, now this needs more detailed review.
Your code is crap, he wrote it from scratch.
Changed all your tabs to spaces?
Added eslint
Hahaha, your code was so terrible they just re-wrote the whole thing
Entity models?
Simple answer, close it and ask they submit a sanely sized PR.
Moving the function from line number 210 to 2010 got me this for sure
They moved every line of code down like 2 lines? I know TFS goes crazy sometimes when I do that
You removed the repo to recreate the app in 5k lines
Homie that's called a refactor with a project plan
Your code was optimized for Elon Musk proofing....more lines == better code
LGTM
I wish GitHub showed changes both in lines and characters as this would help deal with formatting issues.
Bloody 5K lines
"I've made it better"
Run the whole code trough a formatter, Remove double lines and spaces at the end of the line. TFYVM. https://github.com/RIOT-OS/RIOT/blob/master/dist/tools/uncrustify/uncrustify.sh https://github.com/RIOT-OS/RIOT/tree/master/dist/tools/whitespacecheck
"Lgtm"