Accessing historical versions of the cloud copy of the dive log

[Linus Torvalds]

On Sun, Jun 16, 2019 at 12:24 PM Willem Ferguson
<willemferguson at zoology.up.ac.za> wrote:
>
> For data security when something wrong has happened to a dive log, it
> would be invaluable if one could request "Open die dive log as it was on
> October 1st 2018". Is something like this in principle possible with
> git?

Git can maintain a per-branch log of when things changed, but libgit2
(which we use) does not.

Also, even if it were to be there, it's per-repository and doesn't get
distributed out to the cloud (because by definition the dates when
something happened are local - what you saw in one repo back in
October might have showed up in another repository much later).

So the date-based one is not going to be much of an option, although I
guess we could add some way for people to at least see *when* some git
commit was made.

But what you can already do _somewhat_ easily is to get your git
repository (which you get automatically when you sync with the cloud),
and then you can look at the history using "gitk" if you just have git
installed. Not a lot of git knowledge required.

So for example, I can do this:

  # chdir to the cloudstorage cached copy
  cd ~/.subsurface/cloudstorage/...../

  # show the branches (which are basically your user names)
  git branch -a
  * your at email.com
    remotes/origin/your at email.com

  # start looking at history:
  gitk

and now you should see the history. The commits aren't all that
well-named: the name of each commit is just the most recent dive at
that point (dive number and location), but they are often sufficient
to get an idea of what you were doing.

But 'gitk' will also show the diffs and the list of files changed in
the git repository, so you'll see when you added new dives and you'll
see when you edited location names and buddies etc. And you can see
the date when the commit was made (which is not necessarily at all the
date that the dive was, of course - you might be downloading stuff
weeks later).

Anyway, it's not wonderful, but it can give you some idea of where in
the history some point you're interested in is.

And once you find a point that you want to look at in subsurface, you
can actually do that. Let's say that you go back a few months (your
"October"), you can look at the particular commit ID. Yes, it's an
incomprehensible 160-bit SHA1 that shows up as a 40-character HEX
number, but you can cut-and-paste it from gitk (in fact, gitk should
already just auto-paste any commit ID you select).

And then you can do this:

  subsurface ~/.subsurface/cloudstorage/...xyz.../[...abc...]

where that "...xyz..." is your cloudstorage hash (it's unique to each
user you have) and the "...abc..." part is the commit ID you want to
look at (yes, inside actual square brackets, the "[}" around it do
matter)

Is the above *convenient*? No. It's meant for "I know git, I want to
look at history". But you can do it without a _lot_ of git knowledge.

Anyway, that should get you able to look at random state by time, and
you could export that old state from subsurface as an xml file or
whatever, using the normal "save as xml".

You can do fancier things (like actually change your history in git)
if you really want to, but I'd suggest using that "let's _look_ at old
stuff" as the base model. If you start trying to change things, you
cna start making big mistakes that actually corrupt your data.

                Linus