[roganartu]

Perhaps this is a byproduct of the UI (which I totally agree is bad), but this is not true.

`git reflog` contains a full history of all refs you’ve been on in chronological order. Unless you explicitly delete them, dangling refs are not cleaned up immediately. If you rewrite history and realise you made a mistake, you can likely recover by simply resetting the mutated branch to something from the reflog, even days or weeks afterwards (the default reflog retention is 30 days).

[torginus]

You learn something every day!

[alexchamberlain]

Another super simple technique is to create a branch where you start to go back to if you need to; ie if you are rebasing `foo`, start by running `git branch foo-back` and you can always reset back there if needed.

[flurdy]

Since I often play with razors by rebasing, resetting, cherry picking, etc locally - I created a `git tmp` alias so I can play without fear of needing to go reflog diving again.

The `tmp` command creates a commit of all changes, branches it, then rolls back the commit.

[1] https://github.com/flurdy/dotfiles/blob/master/.config/fish/...

[_huayra_]

This temp branch (or even `git tag my_orig_branch`) approach is usually a better on-ramp than the reflog. It's still too easy to misread the line in the reflog of a prior HEAD change and go to the wrong commit, whereas the tmp branch is foolproof (and fatigue-proof).