Can you elaborate on why that's helpful? I rarely get into a weird state with git but when I do it's almost always faster/easier to just delete the repository, re-clone, and re-apply my changes manually.
Can you elaborate on why that's helpful? I rarely get into a weird state with git but when I do it's almost always faster/easier to just delete the repository, re-clone, and re-apply my changes manually.
However, in my experience the most difficult "weird state" to get out of is when you do something that removes/rewrites history. For example: deleting branches, rebasing, squashing, or accidentally getting rid of a reference while attempting to solve some other problem. The root issue is that you want to find a commit that seems like it no longer exists. If you rebase, the branch now points to a new commit that has ansestors you don't want, but the old commit is gone. The "secret" is that all commits that ever existed still exist, you just can't find them in `git log` because the pointers to them are gone. `git reflog` helps solve this by giving you a list of all commits that HEAD has ever pointed to.
git checkout cool-branch # HEAD points to commit abc123
git rebase main # HEAD and cool-branch point to commit def456, but you realize you don't want that rebase
git reflog # reflog tells you that the commit you were just on is abc123
git reset --hard abc123 # HEAD and cool-branch now point to abc123. You've Ctrl+Z'd the rebaseLOL, that hasn’t typically been my experience, but I appreciate the positive attitude.
With reflog I was able to go back before my rebase and redo it again, more carefully this time. (Unfortunately I couldn't just cherry-pick the thing I wanted)
In general it saves you from having to do what you described with delete/re-clone/re-apply things.