21

ugh... i lost code of my best project fuckkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk

And what's even more stupid? it had git versioning. almost around 65 commits. but recent fuckups with laptop crash, offline-online backup confusion led to me loose everything.
I just forgot to do one stupid fuck : git push -u origin master :"""""""""""""""""""""""""(

Comments
  • 2
    I'm a fan of turning on synchronize changes on commit in VS Code for some workspaces.
  • 3
    That's like a horror story
  • 9
    ummmm ... git push???? I always say to my coworkers ‚commit and push often‘. No thanks they say, I rather have it locally and rebase and squash it later so that my git history doesn‘t look like guitar hero ....
    🤦‍♂️
  • 2
    Why did you do that?
  • 6
    @mojo2012 use a separate branch that are pushed to the git server.

    That way you can still squash and clean up before making a PR or rebase and not only do you have a good backup, you can also much easier ask for help.
  • 2
    @Voxera That would require learning more than three and a half git commands. Some people are just too lazy to do that and would rather risk it all *shrugs*
  • 4
    I will blame the stupid fucking auth system of git for 10% of this shit. Git push is like a big thing for me , git commit is like "yeah am super drunk. Let me save my current shit so the upcoming shit doesn't break it " or "yeah am going out for walk. Let's save this shit before my ass cousin comes and deletes random stuff to play some game"

    Also in windows its horrible to make a push : either a stupid open ssh popup comes up or git will pickup credentials from my office public/personal GitHub account.. i have disabled all the credential managers and rather push by entering credentials manually so that's also a more time consuming task.

    What good credentials system you guys use for git/github?
  • 2
    @yowhatthefuck I have to agree, I also disabled credentials since every three months when we have to change password )yes I know, I think its going to change to 2FA) you have to search up the credentials and remove them since git cannot let you just change the password stored when it stops working.
  • 0
    Dafuq? Do you use HTTP or SSH?
  • 0
  • 1
    @yowhatthefuck *disgusted sounds*

    Explains a lot.

    But git utilizes in newer versions the Windows credential store and you can configure the timeout.
  • 0
    Some of these comments make me think not everyone has realized the wondrous simplicity of using ssh keypairs for remote git auth... 😉

    (Hot take, personal opinion) The only use of https for git is anonymous cloning of an open repo. Anything else (certainly pushing to the remote) should use ssh.

    Regarding not pushing to a remote in order to clean up branches (fixup, squash, rebase) mentioned earlier - remind them that as long as they are not on a protected branch, they can always force-push after rebasing, and repeat that as many times as desired. That should obviously be limited to branches only they, individually, are working on (vs. a busy branch with other devs pushing updates), but if you are following a sane workflow, you should be working on your own feature branch for any non-trivial work anyway - then just merge back to the shared parent when you are done.
  • 0
    @cdrice hi. can you tell me more about ssh/https ? I don't understand them much. the university defined these 2 as just layers of OSI/WAP model and I simply remembered them w/o understanding. how are they different in the process of synchronization? how to set them up?
  • 2
    @yowhatthefuck

    I really recommend you read the free git pro book.

    Especially since you seem to obsess over hooks.

    https://git-scm.com/book/en/v2

    You'll find a lot of muey important information there.

    And you should read about SSH / Secure shell.

    The fun part is not SSH per se - but that you can generate a SSH config.

    https://linux.die.net/man/5/...

    SSH is based on key authentication (password possible, too - but makes less fun).

    The private key - which you should never upload anywhere and backup safely - and the public key create a identity.

    The public key can be uploaded to eg github or any other site and is used to confirm your identity, as it is only valid in conjunction with your private key.

    The private key should have an passphrase to prevent misusage - which needs to be unlocked.

    The fun part now is that via SSH config you can set up - several - identities (like passwords) and that SSH has far more possibilities than HTTP.

    Eg SSH can do SOCKS proxying (SSH connect to let an internal server act as an proxy)…

    Setting up a kind of DNS setup by utilizing names...

    Alot of shit.
Add Comment