Earlier we had one folder 'journal_local', when the remote would be
setup a new folder called 'journal' would be created, and each all the
files would be copied over. This meant the local history was being
destroyed.
Now, we only have 1 folder 'journal', and on 'cloning', we add the url
as a remote, and do a git fetch + merge.
This simplifies everything drastically, and opens the door for multiple
remotes.
This reverts commit 763cbf8493c610dec0e7e344bee40ad331e7a272.
This reverts commit ddad699b259bafe6c7ed630e7afc2eb38b7825e6.
This is causing way too many problems -
On Android with GitHub we occasionally get a User Cancelled exception.
On iOS this doesn't work < ios11
I prefer keeping my way till then. Even though it doesn't support
KeepAlive on Android.
This works slightly better on iOS and on Android it has a keep alive,
which will prevent our app from being killed. Additionally, this way
there is less for me to maintain, which is always nicer.
The API for flutter_web_auth is also much simpler.
This also inolves some custom logic for parsing the Query Parameters
from the GitLab callback, as it doesn't seem to be a proper URI. Not
sure what is going on with Gitlab.
Instead lets just use the path_provider. This was being used as for some
reason I wanted the files to reside inside the 'files' folder and not in
the 'app_flutter' directory.
However, that requires maintaining a fork of path_provider, which I no
longer want to do.
We now have a much clearer separation between Git code and this app
specific code. This is awesome, it will allow other people to easily
integrate Git within their apps. Also, eventually it will be trivial to
switch to another implemention of Git (via JGit or a git client written
completely in Dart)
This breaks the iOS version as I haven't moved the code to build the ios
version. Maybe this will be a good excuse for me to setup a proper CI/CD
system for ios builds.
There is also a chance this breaks Crashalytics NDK symbols :(
The Git Api was strange and took a foldeName and it would only allow you
to access git operations in a particular path. This has now been fixed,
and now it can operate in any path.
This was the first step to moving the git api into its own library.
When configuring the Git Repo server, we could optionally track one folder
in the root git repo, instead of just the root folder. This was
specifically to address my use case where I have my journals in a
sub-directory. The setup screen was super ugly, though.
Since now I'm in the process of adding folder support because of #18, I
can remove this hack. It simplifies the code a lot.
It's time to start using a proper logger so we can control the number of
log messages, also - it helps to have a central configuration point for
the logs, specially since I would like to hook them up to Crashlytics in
the future.
It's not perfect as our implementation of git pull results in an extra
merge commit and doesn't handle conflicts properly, but it is a basic
implementation, so at least we have something.
Lets keep it as 'Added Journal Entry', as this way it isn't obvious
that'we loosing the history of the changes when moving from the local to
the remote repo.
Implementing proper migration would take me hours, and its not a
priority right now.
In the case of OAuth errors which we get through the message
channel, throwing an exception doesn't help us as the init function
will not be aware about it.
So for now, I've moved the nodejs style error handling in this
particular case.
For now I've mostly tried to follow the same style guide as the flutter
repository, with many options disabled. Eventually, maybe it would make
sense to be far stricter.
