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.
It's so awesome that I don't need to store the client secret with
GitLab. The GitHub APIs are so much easier to use + documentation, but
at least GitLab supports more OAuth methods.
In this mode the user doesn't need to do anything but give the
GitJournal app permissions, and then it will go and create the repo, add
the ssh key and everything.
This currently does not work for Gitlab.
This just models the basic API that we need for GitJournal. The API
isn't great and could use improvement.
Also, yes, I know I'm committing the secret key, but I don't see any
other way of managing this. GitHub doesn't allow the implicit oauth flow
or dynamic clients registration or anything. So there isn't really any
other way.
This way initially all the changes are performed on the local git repo,
and then later they are applied on the remote git repo. Currently we
just copy the files, but we should be cherry-picking each commit and
applying it properly.
