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.
