BBS pull request documentation overlooks the handling of history rewriting.

[CHD CM Support]

The pull request actually handles commits removed by rebase nicely (e.g. a history cleanup as suggested in Simple Git workflow is simple). Evidently, information about the commits, even the full sources in the state they were in in the no-longer-existing commits, is stored in the database.

But I had to find this out by experient, rather than reading the fine documentation. Any ideas why?

[Adam]

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