> Just go back in time and get a snapshot of what the repo looked like 2 weeks ago. Ah. Except rebase.

This is false.

Any googling of "git undo rebase" will immediately point out that the git reflog stores all rebase history for convenient undoing.

Shockingly, got being a VCS has version control for the... versions of things you create in it, not matter if via merge or rebase or cherry-pick or whatever. You can of course undo all of that.

▲

rich_sasha 4 hours ago | parent [-]

Up to a point - they are garbage collected, right?

And anyway, I don't want to dig this deep in git internals. I just want my true history.

Another way of looking at it is that given real history, you can always represent it more cleanly. But without it you can never really piece together what happened.

▲

nh2 2 hours ago | parent [-]

The reflog is not a git internal -- it is your local repository's "true history", including all operations that you ran.

The `git log` history that you push is just that curated specific view into what you did that you wish to share with others outside of your own local repository.

The reflog is to git what Ctrl+Z is to Microsoft Word. Saying you don't want to use the reflog to undo a rebase is a bit like saying you don't want to use Ctrl+Z to undo mistakes in Word.

(Of course the reflog is a bit more powerful of an undo tool than Ctrl+Z, as the reflog is append-only, so undoing something doesn't lose you the newer state, you can "undo the undo", while in Word, pressing Ctrl+Z and then typing something loses the tail of the history you undid.)

Indeed, like for Word, the undo history expires after a configurable time. The default is 90 days for reachable changes and 30 days for unreachable changes, which is usually enough to notice whether one messed up one's history and lost work. You can also set it to never expire.

It is fine for people to prefer merge over rebase histories to share the history of parallel work (if in turn they can live with the many drawbacks of not having linear history).

But it is misleading to suggest that rebase is more likely to lose work from interacting with it. Git is /designed/ to not lose any of your work on the history -- no matter the operation -- via the reflog.

	▲	rich_sasha 42 minutes ago \| parent [-]
		But it's at best much harder to find stuff in the reflog than to simply use git's history browsing tools. "What's the state of my never-rebased branch at time X" is a trivial question to answer. Undoing a rebase, at best, involves some hard resets or juggling commit hashes. None of it is impossible, but IMHO it's a lot of excitement of the wrong kind for essentially no reward.