It's worth noting that (unless something has changed recently) we don't store commits in the database. Rebased commits aren't actually removed from Git immediately so our UI can still retrieve them. Git behaves this way to avoid users making unrecoverable errors too easily. The general progression towards being gone forever is that the old head is stored in something called a reflog, and will eventually be removed by a garbage collection randomly (I believe the default is sometime after 30 days).
Typically, your PRs will be fine, because you won't look at PRs from a month ago. And if you do, you hopefully don't care about commits you've rebased away so long ago. In case that happens, the UI will degrade gracefully, but won't be able to show you the details of the commits that were removed.
As for your actual question:
But I had to find this out by experient, rather than reading the fine documentation. Any ideas why?
We typically only try to document things that are surprising / non-intuitive and otherwise keep our documentation light to avoid too much noise. I guess handling of rebases is kinda a table stakes thing to us - we didn't expect it to be surprising for you that it would work. For my own education, it might be useful to understand what you expected to happen and what tool you were using previously to understand your expectations.
Cheers,
Adam
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.