This changes the way the SSH keys are managed, they are no longer
managed by the git_bindings plugin and are instead just passed as
parameters. They are now saved in shared_prefs. This allows us to easily
have multiple ssh keys.
It also allows us to store the ssh keys in a more secure storage
location in the future.
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.
It makes the entire code base far more complicated and the round trip to
get the directory really isn't that much. This is a massive
micro-optimization for very little benefit.
This way all the persistant state of the app is managed from the same
place. It makes everything much easier. Also, it's required for when
GitJournal supports multiple repositories.
Make it a ChageNotifier and try to access it through the Provider
instead of like a global variable. This way, the state is better
managed and it'll be easier to split out Settings into smaller classes.
This is quick and dirty way of fixing the problem. It doesn't migrate
the notes from the previous repo and just discards them, so you cannot
move your notes from one repo to another using GitJournal (for now), but
at least its better than having to re-install the app.
Related to #36
For now the only 2 options are - automaitic and manual.
I rather name it "Automatic" instead of "After each change" as that way
I can choose to do it more frequently, if desired.
Fixes#8
This way you can regenerate the SSH Key (if needed) and/or copy it
again. In the future one can add methods to reconfigure the git remote
and add / remove remotes.
