[FEATURE IDEA] Incorporate GIT in Manuskript

[TeebObeeT]

As a user of Manuskript, I want to version my project data and be able to get "back in time" if needed.

The best option is to use Git (Lab|Hub) . Similarly as the function from modern IDE (Atom, VS Code), a possibility to commit (with message) and push directly from Manuskript would be a plus.

Optionnally, possibility to clone and display diff with previous version but this might be an overkill

[RiderExMachina]

I really like this idea and will see what I can do.

[obw]

A Versioning Interface with a kind of PlugIn API would be better on the long run, I personally use SVN for all my personal Project (On my own server, Programming and Writing)... When only one Person use a repository, SVN is more easy to admin then GIT...

[edomaur]

I agree with @obw , a plugin API would be better : I'd like to add support for Mercurial (instead of git) but it's not the only idea I'd like to implement as plugins.

edit: since 2018, my opinion moved to "use git" instead of the plugin approach ...

[olinox14]

a good way to achieve this would be to change the format of the project file (.msk file) to a format like xml. That way you could use the versionning system you want on the file(s) itself

EDIT: Sorry, I wrote a little quickly, I did'nt realize the .msk file was actually a simple zip... But since it is composed of readable files, it's easy to use git or whatever on those files no?

[gedakc]

It is possible to manually use a version control system on the Manuskript project files when the Edit -> Settings value for Save to one single file is disabled as described in Open and Plain Text Format.

[QuantumGrizzly]

I +1 the feature request of providing a built-in tracking of revisions within Manuskript. Since we already have the folder-saving feature, we can already use git or another Source Code Management (SCM) solution outside the software. But it would be nice to manage the entire lifecycle of the project in one software.

I also like @obw's suggestion of using a plugin architecture, so while most people would probably want to use Git, it still makes it easy to implement SCM systems like SVN or Mercurial.

[TheJackiMonster]

I have also started a discussion ( #871 ) to this topic for the refactoring process. I'm not fully sure yet if we should use GIT or SVN but I think we will definitely replace the old revision system with one of these.

[LoveIsGrief]

As a middle-ground, maybe the way forward really is just letting another version control system handle revisions. What could be done is to change the revisions setting to something that allows one to select a version control system. What that does is simply call another executable with the save location as the current working directory upon certain triggers e.g

• git is selected
• An init button is enabled --> git init
• Save: open terminal window with git commit
• Auto save: git commit -m "Autosave $date"
• Show revisions: open terminal and run git log

There could a "custom" option where advanced users choose their commands to be executed. It would also allow using other GUIs e.g TortoiseGit, TortoiseSVN, gitg, GitAhead, GithubDesktop, ...

This would provide at least basic support for revisions and offload it to systems that have already solved the problem. Additionally, it would support any version control system the user chooses: git, cvs, svn, mercurial, fossil, hell even things like rsync, scp, ipfs add, and so on. The sky's the limit.

I imagine it would also rip out a bunch of code and simplify the revisioning system.