Feature request: Import/export file in GitHub repository

[max-mapper]

Hi, I'm a fan of hackmd. I was wondering what you think of the idea of import/export to a file in a GitHub repository. I store all my markdown files on GitHub and would love a seamless way to edit them in HackMD but make sure they are saved back into the repository afterwards.

A user story would be something like:

• When a user clicks the Menu button, they should see a GitHub under both Import and Export.
• When clicking on Import, they should get a file selector that lets them choose the repository and file they want to import into the current editor
• If importing a file into an existing document, it would warn them before overwriting anything
• If they have never authenticated a github account before they should be asked to do the OAuth login with GitHub in a popup window the first time they import or export
• When clicking on export, they should see the same file selector as Import. Note they can also Export without having Importing from GitHub. They should be able to choose a commit message and branch
• They should be notified when their export has saved to GitHub successfully. If there are conflicts in the GitHub repository they should be ignored and the file they chose to export to should be overwritten with the contents of the hackmd
• If they export again later, their choice of file from the first export should be cached in the file selector so they don't have to search for the file again

Another idea might be a markdown button like 'Edit on HackMD' that you could put in markdown files on GItHub. When you click the button it would take you to a HackMD that contains the markdown files contents. In this case maybe the HackMD could be 'linked' to that file so you could avoid the need for the 'file selector' UI described above, as the file would be set at the time you create the HackMD and wouldn't need to be changed.

[jackycute]

Hi @maxogden !
I like your ideas, the user story is very detailed and comprehensive.

We suppose to do the first user scenario and then make a chrome extension to make it bi-directional connected (which might be a bit cumbersome).
And this issue might related to #210

But this bring up another thing that GitHub render Markdown different than HackMD does.
Especially on line breaks, GitHub use two spaces to break but HackMD use true line breaks to break.
The solution will be add the yaml-metadata of breaks: true automatically when you import from GitHub.

Thanks a lot, will definitely love to integration deeper with GitHub.

[almereyda]

Actually GitHub Flavoured MarkDown is less stringt than you expect, as it is just GitLab which comes with strict double-space line breaks.

When working with Jingo, while remembering phorkie, I could grasp a git-distributed text platform, especially seeing it through the federated wiki lens. Since it employed bi-directional syncing with very rough, SSH-key based mechanics, it never felt very webby. With #303 an attempt to go into this direction is available, although this restricts to the use of only one specific repository per HackMD site.
Additionally, #34 (comment) describes a similar level of interoperability, too. Yet it already targets a specific repository per HackMDpad, which also answered the upper need of 'linked' occurences.

From a self-hosting perspective a non-commercial provider as GitLab could be preferred first, but I don't know its API enough to claim it would support such a workflow. The existence of snippet export suggests it might.

[wires]

Just a thought, that is glossing over a bunch of details, but if an API would be available to listen for changes and update the document (as #11), then a git repo could be seen as "just another user".

The git diff should somehow be turned into a OT and something like https://github.com/gabrielcsapo/node-git-server could be used to create a daemon that gives you a hackmd git remote.

[RealizingBlockchain]

It seems from this comment section that a good compromise is for hackmd to implement a special mode with GitHub breaks and all when dealing with GitHub md files. This way you'd allow the rest of the hackmd users use the most convenient md format, while at the same time you can also serve a large chunk of GitHub md'rs(?). No need to choose one or another. The two main market segments that I can identify for such a feature are, 1. the quickly growing user base of creators and maintainers of markdown based static GitHub pages websites like this example. They are elegant, safe, free, and simple to maintain and contribute to. And, 2. ordinary md files users across the vast amount of ordinary repositories. I think it should be a priority to cater to both groups. hackmd is a beautiful editor but this is a pretty obvious pain point. I think this feature would maintain hackmd as an unbeatable product in the long term. Thanks for this great editor, keep up the great work