[flyingcircus3]

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.

[hetman]

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.)

[xelxebar]

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...

[xorcist]

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.

[brown9-2]

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.

[conceptme]

Annotated tags have their own commit I believe that is ehy you should use annotated tags for release tags.

[janpeuker]

> as long as I keep their hashes

that means my hashes or their hashes or them keeping my hashes, I am never sure

[selckin]

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

[delusional]

You never need to do that. git-reflog(1) is the most general solution if you will ever need.

[selckin]

if you're a beginner thats going to be very difficult, restoring the git dir a few times makes the learning process much faster, till it all clicks and you don't need too anymore

[roryirvine]

But then you have multiple copies of your repo which is inevitably going to end up with a my_project_v2_FINAL_3b/ mess, reminiscent of how people used to manage files before version control.

Not having to deal with all that is exactly what git is for.

[Vinnl]

I'm pretty comfortable with Git, but I've still done this a number of times, and in my experience this situation is very evitable. After I've completed my gnarly process (whether successfully or unsuccessfully), I just delete the folder I don't want to use.

[herywort]

Is this a joke? git's whole purpose is to save the history of your project and return to earlier versions when needed

[Vinnl]

It's a super simple solution for which you can be certain that you have all the knowledge needed to perform the restore operation.