Comment by flyingcircus3
2 days ago
After more than a decade of using git, I know that my comfort with rebase, and confidence that I wont make an error I can't undo, comes from knowing that I can always abort. And assuming it wasn't garbage collected, I can always get back to orphaned commits, or the commit before I rebased, as long as I keep their hashes. I can definitely look back on my less confident days as times when I wrongly assumed I was walking a tightrope where screwing up was painful and expensive, and easy to take the wrong path, and abort is the universal solvent to all of that.
I do still find myself tripping up on whether the next appropriate step is to make a commit or continue the rebase, as that is dependent on if you're in a merge conflict or just editing a commit. But even when I get that wrong, and collapse two commits together, abort saves the day.
You don't need to keep their hashes because git keeps them for you. If you realise too late that things went terribly wrong, you can get the pre-rebase hashes with "git reflog". (It can take a little getting used to knowing how to identify them quickly after a rebase but they're there.)
Better yet, git reset ORIG_HEAD or whatever is usually sufficient[0]. The reflog is the general solution, but git's magic references do provide quite a few niceties.
https://www.man7.org/linux/man-pages/man7/gitrevisions.7.htm...
This is a perfect use for tags. They allocate no extra storage space, and act as "savepoints" which you can refer to at any time. (Branches move, tags stay put.) They also guarantee that those loose ends are not garbage collected. Sometimes I delete a bunch of old ones, but any codebase of mine will at any time have a handful of old and probably useless tags. But that's ok.
tags and branches are both just refs to the commit and can be used interchangeably for something like this. tags are not immutable, just in convention.
Annotated tags have their own commit I believe that is ehy you should use annotated tags for release tags.
> as long as I keep their hashes
that means my hashes or their hashes or them keeping my hashes, I am never sure
you can just make a backup copy of .git or your entire project dir. When you get lost, just delete your .git, copy from the backup and try again
You never need to do that. git-reflog(1) is the most general solution if you will ever need.
3 replies →
Is this a joke? git's whole purpose is to save the history of your project and return to earlier versions when needed
1 reply →