This isn't perfect as we're guessing the remote's main branch, but it'll
do. We need this as I'm no longer ever calling 'git clone'. It's always
a fetch.
The good part is that this uses dart_git a lot :)
This doesn't seem to move it to the SD card, but it does move it to a
public location. This is an Android specific feature.
Not sure if this is allowed with Android 11
Related to #99Fixes#154
We now infer this by checking if the directory exists, and by reading
the git config. It's a bit slower, but it's a far better method. I can
add a cache later, if it turns out to be too slow.
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.
Stop it being a singleton. This means it needs to be passed around a
lot. This sucks, but it's how it should be. I shouldn't be using a
global variable to get around this.
This is needed as Settings will soon become repo specific when we
support multiple repos.
This breaks saving the settings in a file, that feature was toggled off
anyway. It needs to be thought over again.
This way we can swap the merge out easily for our own custom merge code.
Also, this makes it easier to do a merge as a way of migrating.
This commit probably breaks stuff on ios
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.
In some rare cases the note just doesn't get saved on disk - in those
cases instead of silently failing we will refuse to exit the note
editor, forcing the user to copy the note and paste it somewhere else in
order to not lose the date.
This isn't the best solution, but it prevents data loss, in a few edge
cases which I cannot reproduce.
Fixes#124
Earlier we would wait till we got the 'mutex' to make a change, however
with the way libgit2 works, during a git push/pull other git operations
such as add/rm/commit block.
So performing a save, while the push/pull is occuring - might have
resulted in a note being lost
Related to #124
This will show all the files and not just the "notes". This way the user
can easily figure out why a file isn't included in the list of notes.
It's currently disabled by default as it clearly needs a lot more work.
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
This way I'll have statistics about how the app is used and more
importantly, figuring out crash reports will be easier as there will be
a rough trail of actions.
1. Actually rename the folder instead of calling rename with the oldPath
2. Inform the parentFolder that a sub-folder has been renamed so it can
accordingly update its mapping.
Fixes#108
The position of the note in the folder doesn't matter as Virtual folders
on top of this sort it according to how to how the user wants them to be
sorted.
This file will be added to save the settings of how we want that folder
to behave. For example - default Editor, view, sorting mode, etc.
This feature is currently disabled as it will only be a part of the pro
mode.
This contains the default editor / view / sortingMode / etc. For now the
folder settings are shared among all Folders. But the idea is that we
should be able to set different settings per folder (real or virtual)
This way in between a git add + git commit, no other git operation will
run. This rarely occurs but it was a posibility depending on the speed
of the users actions.
It doesn't make any difference as -
1. The sort order shown our SortedNotesFolder is different
2. Rebuilds of the tree affect everything. Even the elements which
should be in the correct place.
