Hacker Timesnew | past | comments | ask | show | jobs | submitlogin

Somehow, this seems like a terrible idea.

https://github.com/SriLikesToSing/practice/blob/master/tinke...

What other interesting things could one find in this repository?



The person seems relatively young age wise and thus is probably in the process of learning things.

Edit: the comment was not about code quality but credentials, explained below.

Personally I'd suggest keeping one's code in separate repos with corresponding READMEs, since otherwise it's pretty hard to realize what you were doing a few months down the line: https://www.readme-templates.com/

This is also good for you to decide what can be public and what should remain private. Furthermore, separate repos are a good idea if you ever want any CI introduced for the project, or build any libraries from it. There's nothing wrong with monorepos, but even those are typically used within the context of a particular project or group of projects.


I was more referring to the apparent accidental inclusion of completely unrelated access credentials. That’s something they’re now learning the hard way.

Maybe don’t get in the habit of committing everything in your learning repo, just in case you’ve accidentally saved something else there.


> I was more referring to the apparent accidental inclusion of completely unrelated access credentials. That’s something they’re now learning the hard way.

That's a good point, though! Comment edited, thank you for the clarification.


yeah this seems like a really good idea! I always create new separate repos for official projects so that's always good.



haha yep. I knew this would happen. I would definately be on the more careless side though, and I'm sure that 99% of people would not be as careless as me when uploading their files.


Do note that you can’t just commit them away — in fact, doing that will just create a nice log of things you have deleted, and the files themselves are still a part of the git history.

What you need to do is an interactive rebase, go through all commits, and remove the files by editing the original commits. You can do this with git rebase -i but it is very labor intensive and requires a lot of concentration to get right.

Afterwards your local history will have diverged from GitHub and you need to git push -f to replace the commit history on GitHub with that of your local repository.

It might be a good idea to make the repository private until you have changed all of your passwords and made sure there is no such material in the repository’s history. That doesn’t help if someone already cloned it, though.

Good luck in any case. Hope you have strong passwords and 2FA on your Steam and Gmail.


thank you, I will do this immediately.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: