This is supposed to create a zip of all the files in the repo, and its
.git folder. It's super useful for debugging the state of the repo, and
it's also useful when the remote is down but you still have changes
which you want to export.
Lets use dart-git instead. It seems stable enough, and I'm soon going to
be moving away from libgit2 to go-git anyway. This is the first step towards
that.
Instead we're going to move back to standard exceptions.
Using a custom Result class has created far far more problems
- The Stacktraces aren't always right
- Sometimes one forgets to check the Result error
- All other exception throwing code needing to be converted to Results
- Non idiomatic Dart code
I think it's better to just go back to exceptions. They have their
problems, but overall, I think it's a better approach.
Now the repo needs to be explicitly closed. This way, we avoid opening
and closing the packfiles again and again. It results in the "Reading
Git History .." page taking about 40% less time.
I want all the domain logic to be in the Repo class, this way it can be
performed over another thread / connection. Also, it's far easier to
test this way.
It's not ideal as the hash is now calculated twice, but it simplifies
such a large porition of the code as I can put proper asserts to make
sure all Files in the NotesFolderFS always have a valid GitHash.
This greatly simplifies the entire data flow. Though, it comes at the
risk of introducing bugs, but I think it's worth it.
Plus, it makes everything far far more testable.
This commit is very very slow, and slows the entire app down. It might
be acceptable for external repos, given that this will speed up in the
next one, but it anyway doesn't need to be done for internal ones.
It's better to open the GitRepository fresh each time. Also, in the
future this GitRepository will have a close method, and will keep some
file descriptors open, so it's important we don't leave it hanging.
The repoFolder can no longer ever be renamed. If it needs to be, then
the GitJournalRepo object, must be reconstructed. This simplifies the
entire code base enourmously, as I can mark tons of variables as 'final'
and I don't need to remember to reinitialize complex dependencies when
the repoPath changes.