Add Git version control editor plugin

[Xrayez]

This integrates Git as a version control backend directly using C++ modules rather than GDNative. Initial implementation based on https://github.com/godotengine/godot-git-plugin, and adds https://github.com/libgit2/libgit2 as a submodule to Goost repository.

Unfortunately, it's not possible to select the Git addon via editor interface manually, because the interface was implemented to work with scripts that implement VCS addons. Therefore, unlike GDNative version, the Git addon is initialized automatically here at runtime, without needing to manually to create and assign GDNative-like scripts, which is a nice byproduct.

Additionally, it's not currently possible to use this plugin without patching the engine source. If you'd like to test this PR, you'll need to compile Goost with scons use_godot_patches=yes, this will apply misc/patches/editor_vcs_interface_virtual.patch, but should be possible once godotengine/godot#50219 is backported to 3.x.

Some features are not currently available, like networking (some dependencies have to be satisfied for that), which would be needed for future push/pull functionalities, see godotengine/godot#39255.

Currently tested on Windows (MSVC, MinGW) and Linux.

Co-authored-by: @ChronicallySerious

Why?

The main purpose of having this implemented as a built-in module rather than GDNative plugin is that we'd like to have out-of-the-box experience using VCS. Currently, it takes a lot of steps to start using GDNative-based plugin (downloading the library, copying GDNative scripts). Moreover, if you use Godot as a prototyping tool a lot, you may certainly benefit from having VCS throughout any project.

All you'll have to do is to download the editor and simply start using Git without having to setup GDNative-specific scripts, and it will work for all projects. Speaking of myself, I'd mainly find this kind of functionality useful for prototyping purposes, which allows me to keep the development history (oftentimes important at early development stages, in my experience, because I tend to trash code I think I won't need, but eventually some parts are still useful). Having to setup GDNative scripts for each new project goes against the idea of quick prototyping, for instance see my other repository https://github.com/godot-extended-libraries/godot-main.

Because Godot is highly picky about what kind of third-party software it uses license-wise and size-wise, it cannot allow to integrate https://github.com/libgit2/libgit2 because it's licensed under GPLv2 license. Fortunately for Goost, it's should be still safe to use for editor builds because it's released with linking exception in the license (even Microsoft uses libgit2 for its Git extensions for Visual Studio). This is also the reason why https://github.com/godotengine/godot-git-plugin still integrates libgit2, but there are other reasons why it got implemented as a plugin, of course.

To-do (the v1.0 version)

• Port godot-git plugin v1.x to C++ modules.
• Add a button to initialize git repository manually at Version Control menu option.
• Automatically enable git plugin for the project if git repository is already initialized at startup: Pre-check on .git folder existence godotengine/godot-git-plugin#40
• Do not create initial commit: Initial commit godotengine/godot-git-plugin#23.
• Implement proper staging mechanism: Staging Doesn't Stage Files in Git? (MacOS) godotengine/godot-git-plugin#54.

May be fixable:

• Version control diff viewer doesn't display changes for already staged files godotengine/godot#50427.

[twaritwaikar]

Also what happens when the user tries to add the official Git plugin with this module existing in the engine?

Btw, it's great that you got the v1.x of the plugin working with it and I hope you have seen the v2.0 that's been in the works which basically adds a lot of requested functionalities. It would be nice to have that, in case you decide to integrate that as well, of course!

[Xrayez]

Also what happens when the user tries to add the official Git plugin with this module existing in the engine?

I may try and see how this could affect GDNative plugins, but as far as I'm concerned, this feature may end up being experimental. Resolving memory leaks should likely be solvable eventually, if that's really going to be a problem.

As I said, VCS in Godot's editor could also be improved instead to handle instances coming from modules. I'm basically restricted to existing system that uses script instances to initialize and list VCS providers.

Btw, it's great that you got the v1.x of the plugin working with it and I hope you have seen the v2.0 that's been in the works which basically adds a lot of requested functionalities. It would be nice to have that, in case you decide to integrate that as well, of course!

Yeah, this looks nice, although I'd like to resolve this first and see whether I'd need those features myself, it should be possible to make further enhancements afterwards. It would likely make sense to keep the implementation in sync, but some things may diverge, I think this is inevitable.

[Xrayez]

I've tested this on a native Linux machine now (Fedora), works as well. I'll assume that it will also work on macOS.

The only thing left is making it actually possible to override those endpoint proxy functions via C++, so I've submitted godotengine/godot#50219 patch which should be safe to merge and backport in Godot.

I have discovered other usability issues like forcing initialization/initial commit godotengine/godot-git-plugin#23, so those are also worth to resolve. It would probably make sense to make some things separate from the existing Godot's VCS UI on some level, because I obviously bypass a lot of things to make this work. Fortunately, I have access to both VCS plugin and editor to integrate this well enough.

[Xrayez]

I've decided to manage object instances separately from script instances:

The plugin is now automatically enabled if Git repository is detected at startup, which resolves godotengine/godot-git-plugin#40.

It would likely make sense to introduce an editor setting to prevent automatic initialization at startup, since GDNative users might still want to use GDNative implementation.

[Xrayez]

It would likely make sense to introduce an editor setting to prevent automatic initialization at startup, since GDNative users might still want to use GDNative implementation.

[Xrayez]

I have resolved the issue with staging files as described in godotengine/godot-git-plugin#54. I'm still using the v1.0 API of Godot's VCS interface (v2.0 is still WIP in Godot).

We still have to wait for Godot to backport already merged godotengine/godot#50219.

That said, I'd say this PR is completed now.

Note to self: remove misc\patches\editor_vcs_interface_virtual.patch once godotengine/godot#50219 is backported to 3.x.

[Xrayez]

I've done a bunch of other usability stuff as seen above. I've also attempted to replicate VS Code functionality of Ctrl + Enter, but figured that it would be too hacky to do in Goost. Due to this, I created godotengine/godot#50432 which should hopefully be available in Godot 3.4.

godotengine/godot#50219 is already cherry-picked in godotengine/godot#50416 which is required for this feature to work in Goost.

Due to this, I see no reason why this cannot be merged now.

According to Godot contributors chat discussion, the push/pull features are unlikely to be backported to Godot 3.x, see https://chat.godotengine.org/channel/editor?msg=KaZBJ9MupK66tPhjC.

[Xrayez]

This is the first PR which introduced a new git submodule.

For existing users, you'll need to git pull and git submodule update --init --remote in order to compile the git module. 😃