Today I did a git push --force, then I had to create a branch out of the old code, but other times I had to save the files I worked on, delete the local repository, git clone again, then reapply my fixes. I want to at least have a bookmark on how to fix things in the future.

Yes, I’ve heard about VSCode plugins, that supposed to help. But no, I don’t want to use a glorified webpage to do coding, regardless if it’s directly tied to Micro$lop, or some of the slop was removed by 3rd parties. I tried KATE once, I cannot go back to some sluggish webpage, which only argument for use at the moment is “but it has plugins”.

  • itsathursday@lemmy.world
    0·
    11 days ago

    Since no one is answering directly, here’s the steps to follow and you can go from here to find the specific commands. If you want to get back to a specific point in the history of the remote repo as a means to undo a mistake, and then continue from that point with any changes then usually you want to do this in a non-destructive way. ie. accept you screwed up and don’t cover it up.

    There are many ways but this is the way that works.

    • Keep a second copy of the local repo with the current state and changes you’ve made. If you screw up git commands this is your physical reset and save point for the repo history log and changes you made.
    • Find the commit in git log you want to go back to and save that commit hash.
    • Git checkout that commit in you local. You are now in the point at the past before it all went to shit.
    • git diff the files that you want to apply changes with the ones in the copied repo and create a patch file. There are many ways to solve this, but this way you have a physical record of the changes, seperate from the git repo and you can do with them what you like. Include read and view them yourself.
    • git checkout to main again on latest commit/head
    • use git revert to utilise the built in undo convenience this provides by taking the state of the local repo to the commit hash in the past and committing changes to make this possible on top of the current state to make it the same but without erasing the history that you screwed up. All changes are additive even the ones to remove changes.
    • now git push (without the force since you are not a jedi by any means and this is a humbling moment on this path to become one)
    • now create a new branch for the changes you originally intended to make and pretend you haven’t wasted this time and are actually net positive because of the learning experience
    • apply the patch files to the files you want to change and hope they apply, if not, manually resolve any merge conflicts by hand
    • commit the changes to the local branch
    • push the branch to remote
    • do a pull request and summarise what all the changes are in the branch
    • merge the changes into main branch and squash the commits
    • realise that your original method is really no different as to the result, just now you have some more fancy ways to achieve it