Replies: 1 comment 6 replies
-
Right out of the gate - thanks for the great insights! Git integration is planned as one of the most important features for the stable release. It'll take some time as there are many things to implement to get Git integration right. In general, I think that the planned Git support should address the points you've made. I'm primarily inspired by Git workflow in code editors like VS Code, and I'll try to replicate it to some extent. The idea for a possible workflow looks like this:
I think, if this can be achieved, it'll make for a pretty comfortable and versatile workflow. I'm happy to learn what you think of this plan. On a side note, the "Version control" on the main page refers to a different, in-editor feature, similar to Version history in Google Docs. Vrite already stores the history of edits done to the file (though it is currently reset when the content is updated via the API) and the goal is to provide a UI (and API) that allows you to navigate through this history and revert back to previous steps. |
Beta Was this translation helpful? Give feedback.
-
I saw the "Version control - coming soon" homepage block.
This is the main feature I'd need to try and push for vrite adoption at my workplace. I want to replace all google docs for feature specs and on-boarding guides and other internal documentation etc with vrite.
I have some thoughts about version control integration. I used https://github.com/getgrav/grav in the past and I have some experience with their git integrations.
The main decisions I can think of are (1) what to commit, (2) when to commit, (3) where - which repo & branch, and (4) conflict resolution.
Regarding (1) & (3) - I think it's a workspace git integration config. Maybe have include patterns. All included markdown files will be loaded to a default column ("published"?). Upon creation of a new page you can opt in to include it the tracked files or just always track all.
Regarding (2) when - I think we can use the groups (columns) to trigger commits. For example when moved from "draft" to "published". Maybe a published document must move back to "draft" for editing.
(4) Nice UI for conflict resolution would be great, but something as simple as default's vscode conflict handling is good enough.
We'll probably need a "refresh" button.
I had a bad experience with grav that had periodic commits, I don't think it's a good direction.
Beta Was this translation helpful? Give feedback.
All reactions