8
10Dev
3y

Me: Ok I've updated the docs, I'll open a PR with the changes

Maintainer: Looks great! Can you remove the changes to the package-lock.json? (I assume it got updated when you ran npm install to start the webserver)

Me: Ok sure, I'll update it soon

And this is where the troubles begin. The file was commited 2 commits ago, so I have to roll back to then. However, the remote repository has been updated since then, so I git fetch to keep up to date.

This makes the rollback a hell of a lot harder, so I run git log to see the history. I try a reset, but I went back to the wrong commit, and now a shit ton of files are out of sync.

I frantically google 'reset a git reset', and come across the reflog command. Running that fucks things up even worse, and now so much shit is out of sync that even git seems confused.

I try to fix the mess I've created, and so I git pull from my forked repo to get myself back to where I was. Git starts screaming at me about out of sync files, so I try to find a way to overwrite local changes from the origin.

And by this point, the only way to describe what the local repo looks like is a dumpster fire clusterfuck that was involved in a train wreck

I resolved the mess by just deleting the local copy and git cloning again from my fork.

I gotta learn how to use Git better

Comments
  • 4
    You can always just check out an old version into another folder and copy that one file by hand into the actual dev repo if you are that bad at reading StackOverflow answers.
  • 3
    Always that I have to do something like that, I create a new temporaly branch, if anything happens I just delete it and start again. On the company projects any simple trouble can be a fucking giant trouble in seconds
  • 4
    Rule number 1 should be:

    Don't fuck with git internals.

    Certain commands, e.g modifying the reflog, shouldn't be used by an user.

    The branch hint from @rittmann is _very_ important.

    Many people have very fancy workflows - git isn't fancy, it's pragmatic.

    Whenever in doubt, branch off.
    git switch / git branch are your friend.

    You can create as many branches as you want - space won't increase as long as you don't change stuff.

    git branch -c doesn't mean create.

    It _means_ copy.

    another case of don't use short variables, it gets easier.

    git branch --copy old-branch backup
    git branch --copy old-branch fuckity

    Now do whatever you want in fuckity.

    Keep old-branch intact for comparison / pulling / merging stuff.

    Backup if things go wrong.

    Fuckity for unclogging the stuff.

    git reset --soft <commitId> does a soft reset.

    Your file changes get reset till the last point.

    Just recommit without the changes you don't want and be done.

    Many people prefer rebasing, cherry picking, and tons of other stuff.

    Imho they're not wrong - git allows it.

    But if you have a simple solution, and you're unsure, git reset --soft and branching is the best workflow.
  • 0
    @IntrusionCM how can I save this comment?
  • 1
    Hm. Sent yourself a Weblink to the rant via the share button in App and copy / paste?
Add Comment