Today we released infinite history for all notebooks, which works retroactively. You’re now able to browse history, revert to any version, fork from versions – as long as you own or have access to the notebook. This is especially neat for teams, because you can browse back to any point in time and see who made edits.
History is reactive - so when you’re browsing, you see the notebook at that state. As you move around, the notebook is changed incrementally to match the point in history, so if you’re browsing something animated, it keeps spinning. If there are inputs, they keep their values. It’s very live.
— reverted changes are in the history, which could be a problem especially in a Team (pasted a password… oops… tried something on a Team notebook which I should have tried in a fork… oops…); alternatively, a possibility to purge a revision from the history (à la git squash)
— In my browser the dates are in French, mixed with the rest of the UI in English: not too good (all in the UI consistently in English would be better).
— When merging a fork, we get an element of history for each cell; it’s not bad per se, but it would be cool to group them in a way
— Would love the ability to search/filter on cell contents (“when did I change geoAiry to geoAirocean?”)
— Would love to be able to pin some revisions with color labels, or annotate (though the “Shared” or “Published” labels are already doing this job in way)
— Would love to see the diff view for the selected cell
A tiny bug: yesterday’s edits (at 11:29pm in France) are shown in the history panel as “today 11:29pm”, and I can assure you they were not today 11:29pm since it’s only 16:38
Unlikely, and because it’s an endpoint that requires authentication you won’t even be able to use a proxy. Your best bet will probably be a user script or content snippet that executes in the parent context (depending on if/when/why you need to fetch the data).
Yep, that assumption is right - /history is, like other user-specific endpoints that confer private data, designed to secure to the application rather than usable as an API. We’ll likely have an API that has proper authentication, documentation, and guarantees, but for now that endpoint isn’t intended to be programmatically accessible.