When dealing with cloud storage most of the time the user will not be
familiar with git. So if the local cache is corrupted don't leave them to
clean up the mess. Instead just move things out of the way (just in case
they know how to extract data from the damaged local repository) and ask
them to restart the operation which should give them a fresh copy of their
data from the remote server (minus any local changes that hadn't been
synced to the server before things went bad).
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
If a user gets stuck accessing cloud storage it's often hard to figure out
which step is hanging which makes it much harder to narrow down the
problem. With this patch calling Subsurface with '-v' will give somewhat
finely grained progress information on stderr.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
If Subsurface is started with the verbose flag, also give progress
information on the consol (just in case there are issues with the progress
dialog).
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
I hate this patch. But it makes no sense to expose users to git level
error messages. So this is trying to make things much easier (and,
frankly, less informative) if we are accessing the Subsurface cloud.
The way this is implemented is really ugly; it tries to avoid frequent
repetition of the same strings by using different exit points for the
functions in question. I'm not convinced this was the best way to do it
but it's what I have.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The callback function was introduced in 0.23, so put it behind that
ifdef.
Signed-off-by: Anton Lundin <glance@acc.umu.se>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This one sadly only appears to be called with 0% and 100% in my examples.
Not sure what to do about that.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Since the spinner caused all kinds of problems inside VMs, wasn't shown at
all for some people on Win10 and appeared to get stuck a lot and still
left people with the perception that Subsurface was hung, this patch takes
a more traditional approach and gives the user a progress dialog.
An additional benefit of this is that the user now can cancel a hung
transfer.
The slightly weird passing in of the callback allows for the separation of
UI and core logic code...
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
All this really does is make sure that the fast forward works if the local
cache has received updates that haven't made it to the server, yet.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We shouldn't always tell the user about the perceived validity of the
cloud certificate - we force it anyway.
But it's nice to be easily able to see if we tried to update the remote,
so add another debug output when run with -v
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This seems to do the right thing in several cases that I tested, but I'm
worried if it might end up causing us data loss in other cases. This needs
a TON of testing.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Because of the structure of some of our files git too easily assumed that
they were renames and that confused the merge algorithm.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
In many cases Subsurface will do something "reasonable" if we have
conflicting edits and then try to merge. GIT_MERGE_FILE_FAVOR_UNION means
that both edits will be added to the final file and then Subsurface should
quietly take one or the other - this will need quite a bit of testing.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We still punt if there are any conflicts (which are likely to occur if we
have touched dive sites in both changes). But in my testing at least for
fairly simple, non-conflicting changes this works and creates a correctly
merged tree.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
On some platforms like Android the installed root certificates are rather
inconsistent. Same goes for older Windows machines. Instead of trying to
figure out how to get the user to install the right root certificates
(just kidding) we explicitly recognize our own server certificate and
allow that to override the validity assessment by the OS.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
It makes sense to hide git URLs from the end user in release builds, but
while developing and testing it's better to get more detailed information.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Oops, this is bad as it will lead to a certain buffer overrun.
The other change is more cosmetic - nested open comment '/*'.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Commit e21cae2d46 ("Cloud storage: sync the remote after save") broke
regular git saving without any remotes: it would never initialize the
"remote" pointer, and then use that uninitialized remote pointer to see
if it was a cloud storage remote that it should try to sync.
Fix it.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This isn't perfect, but at least tells the user if we weren't able to
connect and are working just off the local cache.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This creates the basis to allow other backends to be used with the cloud
storage infrastructure.
So far this should all just transparently continue to work. A user would
have to manually add the cloud_base_url entry to the CloudStorage section
in their config file in order to use a different backend server.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
I have no idea whether the semantics is right, this patch was only
written so Subsurface compiles against the current stable release of
libgit2.
[Dirk Hohndel: added an extra conditional so this also compiles with the
curl-stream branch needed for https proxy support in
libgit2]
Signed-off-by: Gaetan Bisson <bisson@archlinux.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We were falling of the end of a number of functions that were supposed to
return 0 on success or an error.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
There's no point in telling the user that the remote is empty. We need to
instead fix that and create the local cache and set things up for the
remote.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
When we first store things to the remote there won't be a matching branch
for it. And even if for some silly reason the remote branch got lost -
what's the point of telling the user that there is no remote branch? What
are they supposed to do about it. Let's just fix the problem and move on.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
If we don't have a repository yet, we can't setup the proxy option before
calling into libgit2. Instead we use a callback.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Instead of showing the git URL and talking about failures to clone
repositories, simply tell the user what's happening with the cloud
storage.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Also change the name of the enum and make sure all the inner functions get
passed the remote transport information.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This change once again tests if the remote can be reached. Even with a
fairly big data file and a medium speed internet connection the remote
sync is fast enough to call it nearly instantaneous. Maybe a couple of
seconds.
We may need more checks / different heuristics / warnings if the sync
didn't happen, etc. But for now this should allow more reasonable testing.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
libgit2 takes forever (a minute or so) to figure out that it can't connect
to a remote server.
So if we are using https as connection protocol, quickly check utilizing
RFCs 2324/7168 to make sure we can reach the cloud server (and not some
captive portal or something).
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The settings are stored in the local cache repository - so without
resetting it a proxy would stay configured even if it was disabled in the
Subsurface preferences.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
At the time of this commit support for this feature has not landed in
upstream libgit2, yet (but there is a pull request). Yet supporting this
here doesn't appear to cause any issue with older versions of libgit2,
either, so the http proxy support will simply not work when enabled and a
version of libgit2 that's too old is used.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Again, note that this currently only happens when you initially open the repository.
So if you do
subsurface https://.../repo[myubranch]
it will start up by fetching the remote information, and updating the
local cache. If you then download new dives, and do a save-and-exit, it
will save to the local cache, but it doesn't do the fetch at this point,
so the remote is now begind.
The *next* time you start subsurface, and load that git branch again, it
will fetch the remote, and now notice that the local cache is ahead of
it (because you downloaded new dives and saved them locally), and *then*
it will try to update the remote with the new information.
This is obviously bogus, but we will need to decide exactly how we want
to sync with the remote repository. But now the core functionality is
there, it's just that we need some interface to say "sync now".
Especially in the face of spotty (or non-working) internet, you want a
GUI etc for this whole remote sync, rather than doing it unconditionally
and silently whenever you load the local cache initially.
With that caveat:
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
I'm going to try to update the remote if the local cache is more recent
when we fetch the data, which requires access to the remote over a wider
range of code. This re-organizes the code so that we can free the
remote later without having to have nasty error handling.
We avoid the whole "if an error happened, free the remote and return" by
creating helper functions and freeing the remote in the caller, so that
all paths end up freeing it naturally.
NOTE! We want to try to update the remote when we save the local cache
too, so this whole "update remote when opening it" is incomplete. But
(a) we do want to do it here as well
and
(b) this is the easiest place to create the initial "push to remote"
code without any new "sync with cloud" interfaces.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We used to fetch the remote information but not actually do anything
about it, except report when it wasn't up-to-date.
Now we actually update the local cached copy if the remote has changed.
The code does not try to actually merge things, so only fast-forward
updates are done, but that should be the normal case. We might
eventually do some simple merging on our own, but I suspect manual
merging may be the safer option.
We don't currently ever update the remote repository, and only inform
users that our local repository is ahead of the remote. Fixing that is
the next step.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Since we use the email address (including the '@' sign) as the repository
name we have to be more careful when trying to pick an account name from a
git URL.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
