I'd love to see "sync with git" become a standard app feature.
Too many app developers realize they need some kind of shared state "in the cloud" and end up with a database and a backend server. Many of them would be better off if they had a reliable way to push the state management to a user-controlled space, like a git repo or Dropbox
1. Decent desktop apps to sync the data, not everyone is comfortable hacking a Cron script. I've started with that - https://GitHub.com/GitJournal/git-auto-sync - but it's in the early stages.
2. For mobile apps, a way to drastically reduce the overhead. Cross compiling libgit2 + deps + NDK is a major pain, and jGit uses more modern java features so you need to target a higher version of Android. (This was in early 2019, when I first started GitJournal)
3. There is no competing with a simple http call vs the complexity of git. Plus the entire onboarding process.
4. Many many apps do write to Dropbox or Google Drive, but for me that's not a win as you aren't in control of your data.
5. While hosting your own git server is arguably easier than self hosting anything else, the majority of users in GitJournal (more than 80% use GitHub, this was about a year ago.) There is also a bias as people who self host are more likely to switch off the analytics. I don't send any message when analytics are switched off, so I don't know.
6. We need end-to-end encryption in Git, like keybase was providing, but open source and hostable in any git repo. I started a proof of concept of a custom remote where I just write all the git objects to another git repo, but haven't gotten very far.
Hi Vishesh, I installed the app on ios just now and tried to connect my repo on GitHub. It failed with the error - MissingPluginException (No implementation found for method gitClone on channel gitjournal.io/git)
I’ve requested a refund. But please don’t take that as discouragement. I want this workflow (editing markdown notes synced to git) very much. I’ve tried various ways to hack it, like connecting 1Writer (editor) to Working Copy (git client). Although both apps are very slick, the integration is not.
Editor apps are also reluctant to provide git integration for the reasons you listed, plus it will reduce future revenue from a hosted solution they could offer. I’m not too optimistic that there will be many apps in this space. That’s good news for you!
My apologies, I introduced a bug and didn't expect this to get posted on HNs. The fix is pending review on iOS, so hopefully you should receive it soon. (Version 1.85.1 has the fix)
Regardless, I'd love it if you could reach out to me (vhanda at gitjournal.io) and explain your workflows, additionally, I'll be happy to provide you some coupon codes so you can try the basic version of GitJournal without paying. Especially considering your horrid experience.
Even when 80% use one platform, the fact that you can very easily switch between platforms (commercial or self-hosted) is of significant value—vendor lock-in is completely eliminated.
Syncthing works well when devices can find each other (usually over mDNS) and are online simultaneously. After dealing with an entangled mess of introducers and devices, I decided to setup an old phone running Syncthing-Fork as root (otherwise mDNS doesn't work on Android), use it as a central introducer and always-online file host, and put my shared files there. It works pretty well, but I still run into cases sometimes where one client learns of the existence of files from another device, but the other device is offline and my central server doesn't have copies of them.
For locally shared documents, I sync them with Syncthing and edit them on Android in Markor, and it works pretty well.
I got different markdown editors on different devices and didn't want to use a public / cloud hosted git repo for my notes.
It works fine, as long you don't get in contact with iOS.
I got many devices and often let it sync my phone when I'm at home, because I'm struggling already enough with battery lifetime.
I also got it running on one of my dedicated servers, so I got an offsite backup, with systemd you can set it on autostart after an internet connection was established, so I don't really have to manage it anymore and I only see it basically in the logs of the packages that I update.
That's awesome. I use it pretty much the same, only I sync the root of my phone data too. So I can take a photo on my phone and have it pop up on my computer, ready to use.
My only small tip for readers here is be careful treating any node as a safe backup.
A device that accidentally deletes everything in a folder will propagate out if you don't notice it happened.
But TBH in practice (as a very heavy user for my usecase) it's very rare, and a traditional backup system will cover you perfectly.
These are great points:
I also feel that one other big problem with notes is organizing them properly as number of notes increase. Since git has history for all your changes you can easily delete anything that is not important right now.
I am building a side project exactally to solve this problem. It has auto sync also. The plan is to add search functionality that can search accorss the history of all the notes.
https://upnotes.io
Also in upnotes we are using your local git command and I am planning to add encryption with your public key for few subfolders.
Create a note by pressing plus, select share and click OK. Now you got two notes in the app that are copies.
The first few minutes are the most important for an application. It should not fail and do as advertised. So far, this feels not fully tested or even UI tested. This would not lead to an easy upgrade to 'Pro'.
Note: removed statement about not intuitive of Git syncing. This is hidden in the hamburger menu instead of being part of the initial view and options.
The Git model is to version everything together. This means that a conflict blocks the entire repo until it's fixed.
In many situations, it's better to version separate pages/items/notes separately, and have a conflict to a single note leave the rest of your repo working and syncing.
sync to git isn't perfect. I use Google Keep, which, like docs, I can have the same document open on multiple machines, start editing on one, finished editing on the other, no "commit/push/fetch/rebase/merge" cycle required.
The typical scenario for me is start typing something in and then get interrupted (notification, time based appointment, someone needing my attention), when I get back to entering I might be at a different machine (like started on my phone, got interrupted, then sitting at my computer and remember to finish).
Git stores the entire history of text files. Very few apps need the history feature. Leaving the feature in place may take much disk space, and actually removing files no longer needed is a pain in git, git is not designed for that use case.
I do agree that a standardized sync protocol and file format that could be pointed at any arbitrary server would be terrific. I just disagree that git is that format for many use cases.
To be honest I'd rather love to see "select folder for storage" become a standard app feature. Then I could just use whatever app I want to synchronize the files (in my case probably Syncthing). Integration of $APP_FEATURES and $SYNC_BACKENDS in apps is a major waste of developer resources and it also means that, as a user, I can never freely choose the app based upon its intrinsic features but also always have to keep synchronization in mind.
The iOS editor Runestone takes this approach. I’ve installed Möbius Sync on the device, with both apps pointing at the same folder to create a syncthing conduit with my Mac.
I wish we just had save to textual flat file as a more common standard app feature (which is simple/easy) and a plethora of separate apps that did the syncing from that (hard - conflicts/authentication, but only needs to be done once for all apps).
I have the git syncing tools but most apps dont save to flat file and the ones that do tend to require hitting export -> backup.
That’s a great idea. Although key management might be a problem. Also, you might have conflicts if you try to push from one device after having previously pushed from another device.
Conflicts aren't specific to git. Git offers a history of those conflict resolutions though, which lets you correct them if they were not done right.
I used to store my DayOne journal in git, and boy, their cloud sync conflict resolution was sometimes quite destructive. Having the git history showed me that, and allowed me to correct it.
Too many app developers realize they need some kind of shared state "in the cloud" and end up with a database and a backend server. Many of them would be better off if they had a reliable way to push the state management to a user-controlled space, like a git repo or Dropbox