Pure C# backend for GitExtensions (with NGit)

[ArsenShnurkov]

I know 3 types of backends:

1. external command line tool (which is called with environment variables and streams redirection)
2. native library wrapper (libgit2 - https://github.com/libgit2/libgit2sharp)
3. pure C# code (NGit - https://github.com/mono/ngit , which is newer than frozen GitSharp project)

What is the state of implementation of the third way?

[jcoder76]

I think that NGit should be a good option, but they need to dispose of the use of sharpen, at least the linked libraries (posix support). It is bound by an uncomfortable license agreement and may become unsupported. Their community support page is down as of this writing:
http://developer.db4o.com/Projects/html/projectspaces/db4o_product_design/sharpen.html
Access to their repository is still open, but I could not access their "GPL interpretation".
Needless to say, the future of the library is questionable.

License policy:

Sharpen Open Source Java to C# Translator
=========================================

* The sharpen home page is http://community.versant.com/Documentation/Reference/db4o-7.12/java/reference/Content/sharpen.htm
* The sharpen source code is available at https://source.db4o.com/db4o/trunk/sharpen/
* `sharpen.core-1.0.0.jar` was copied from https://github.com/mono/ngit/blob/master/gen/plugins/sharpen.core_1.0.0.jar


Copyright (C) 2004 - 2008  Versant Inc.  http://www.db4o.com

sharpen is free software; you can redistribute it and/or modify it under
the terms of version 2 of the GNU General Public License as published
by the Free Software Foundation and as clarified by db4objects' GPL 
interpretation policy, available at
http://www.db4o.com/about/company/legalpolicies/gplinterpretation/
Alternatively you can write to db4objects, Inc., 1900 S Norfolk Street,
Suite 350, San Mateo, CA 94403, USA.

sharpen is distributed in the hope that it will be useful, but WITHOUT ANY
WARRANTY; without even the implied warranty of MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
for more details.

You should have received a copy of the GNU General Public License along
with this program; if not, see https://www.gnu.org/licenses/

[vbjay]

Did you notice the libgitsharp branch

On 1:10pm, Mon, Dec 1, 2014 DaFlame notifications@github.com wrote:

I think that NGit should be a good option, but they need to dispose of the
use of sharpen, at least the linked libraries (posix support). It is bound
by an uncomfortable license agreement and may become unsupported. Their
community support page is down as of this writing:

http://developer.db4o.com/Projects/html/projectspaces/db4o_product_design/sharpen.html
Access to their repository is still open, but I could not access their
"GPL interpretation".
Needless to say, the future of the library is questionable.

License policy:

Sharpen Open Source Java to C# Translator

• The sharpen home page is http://community.versant.com/Documentation/Reference/db4o-7.12/java/reference/Content/sharpen.htm
• The sharpen source code is available at https://source.db4o.com/db4o/trunk/sharpen/
• sharpen.core-1.0.0.jar was copied from https://github.com/mono/ngit/blob/master/gen/plugins/sharpen.core_1.0.0.jar

Copyright (C) 2004 - 2008 Versant Inc. http://www.db4o.com

sharpen is free software; you can redistribute it and/or modify it under
the terms of version 2 of the GNU General Public License as published
by the Free Software Foundation and as clarified by db4objects' GPL
interpretation policy, available athttp://www.db4o.com/about/company/legalpolicies/gplinterpretation/
Alternatively you can write to db4objects, Inc., 1900 S Norfolk Street,
Suite 350, San Mateo, CA 94403, USA.

sharpen is distributed in the hope that it will be useful, but WITHOUT ANY
WARRANTY; without even the implied warranty of MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
for more details.

You should have received a copy of the GNU General Public License along
with this program; if not, see https://www.gnu.org/licenses/

—
Reply to this email directly or view it on GitHub
#2516 (comment)
.

[sharwell]

@slluis and I have done quite a bit of work to improve Sharpen. If you look at the running history of the master and sharpen branches in the tunnelvisionlabs/antlr4cs repository, you'll get a good feel for how to use sharpen without the dependency problems.

[linquize]

let me study antlr4cs

[jcoder76]

@vbjay do you have a link to the source? The libgitsharp branch you speak of?

[vbjay]

https://github.com/gitextensions/gitextensions/tree/LibGit2Sharp
https://github.com/gitextensions/gitextensions/tree/feature/LibGit2SharpPerformance

On Mon Dec 01 2014 at 8:12:26 PM DaFlame notifications@github.com wrote:

@vbjay https://github.com/vbjay do you have a link to the source? The
libgi

—
Reply to this email directly or view it on GitHub
#2516 (comment)
.

[vbjay]

See #1996

[slluis]

@sharwell that's very nice progress indeed!

In MonoDevelop we are moving away from NGit because, even if it works, it has been increasingly harder to keep it up to date with JGit. Sharpen has limitations and bugs, so every port requires manually tweaking both the Java source and the generated C# source. Also, when some of the dependencies of JGit changes, a lot of work has to be done in NGit to make it build. We have implemented our git add-in using LibGit2Sharp now, and it is almost ready to replace the NGit based one.

[sharwell]

@slluis The reason it's so hard to keep patching the Java/C# code is the NGit project isn't using Git to handle the port. If you look at the branches of tunnelvisionlabs/antlr4cs that I referred to (specifically as a graphical history), you can see that each time the sharpen branch is merged into the master branch, Git automatically merges changes that were made to the C# code (in the master branch) with changes that were made to the Java code and/or the Sharpen implementation (in the sharpen branch). The cs.patch and java.patch files used by NGit are not only unnecessary, but they are highly error prone and difficult to maintain compared to letting Git do exactly what it was made to do.

At this point, the only real frustration I have is Sharpen being so closely tied to Eclipse, making it somewhat difficult to automate within the existing Maven+PowerShell tool chains we use elsewhere in ANTLR.

[slluis]

@sharwell I've been in charge of keeping NGit up to date, so I should know very well what are the hard parts, shouldn't I? I know there are other (and maybe better) ways of patching the code, but that's not the real problem. After all, cs.patch and java.patch are generated using git tools, so at the end all you have to do at every import is to resolve conflicts, just like you would need to do if you were using git forks and branches.

The really hard parts are:

1. Java constructs that make sharpen crash. When sharpen crashes is not always easy to find out what caused the crash.
2. Java constructs not supported by sharpen.
3. Incorrectly generated C# code. It has to be manually patched.
4. Missing implementations of core java methods. Those have to be implemented or mapped to existing .NET methods using the configuration file.

Some of those problems could be alleviated by improving Sharpen, but only to some extent, since there are some Java constructs which are not easily translatable to C# (and JGit uses many of them).

[vbjay]

So because of that, why are you trying to go from one language to another
to get the result instead of using a libgit2 flavor?

On Wed Dec 03 2014 at 11:28:02 AM Lluis Sanchez notifications@github.com
wrote:

@sharwell https://github.com/sharwell I've been in charge of keeping
NGit up to date, so I should know very well what are the hard parts,
shouldn't I? I know there are other (and maybe better) ways of patching the
code, but that's not the real problem. After all, cs.patch and java.patch
are generated using git tools, so at the end all you have to do at every
import is to resolve conflicts, just like you would need to do if you were
using git forks and branches.

The really hard parts are:

1. Java constructs that make sharpen crash. When sharpen crashes is not
   always easy to find out what caused the crash.
2. Java constructs not supported by sharpen.
3. Incorrectly generated C# code. It has to be manually patched.
4. Missing implementations of core java methods. Those have to be
   implemented or mapped to existing .NET methods using the configuration file.

Some of those problems could be alleviated by improving Sharpen, but only
to some extent, since there are some Java constructs which are not easily
translatable to C# (and JGit uses many of them).

—
Reply to this email directly or view it on GitHub
#2516 (comment)
.

[vbjay]

https://libgit2.github.com/

On Wed Dec 03 2014 at 11:31:38 AM Jay Asbury vbjay.net@gmail.com wrote:

So because of that, why are you trying to go from one language to another
to get the result instead of using a libgit2 flavor?

On Wed Dec 03 2014 at 11:28:02 AM Lluis Sanchez notifications@github.com
wrote:

@sharwell https://github.com/sharwell I've been in charge of keeping
NGit up to date, so I should know very well what are the hard parts,
shouldn't I? I know there are other (and maybe better) ways of patching the
code, but that's not the real problem. After all, cs.patch and java.patch
are generated using git tools, so at the end all you have to do at every
import is to resolve conflicts, just like you would need to do if you were
using git forks and branches.

The really hard parts are:

1. Java constructs that make sharpen crash. When sharpen crashes is not
   always easy to find out what caused the crash.
2. Java constructs not supported by sharpen.
3. Incorrectly generated C# code. It has to be manually patched.
4. Missing implementations of core java methods. Those have to be
   implemented or mapped to existing .NET methods using the configuration file.

Some of those problems could be alleviated by improving Sharpen, but only
to some extent, since there are some Java constructs which are not easily
translatable to C# (and JGit uses many of them).

—
Reply to this email directly or view it on GitHub
#2516 (comment)
.

[slluis]

@vbjay that's what we are doing, we are moving to libgit2.

[vbjay]

Recommend this be labeled discussion. Seeing the fact that the libgit2charp branch last commit was Aug 31, 2014 but the branch is 48 commits behind libgit2:vNext it looks like they are ramping up dev on the library side.

[ArsenShnurkov]

why are you trying to go from one language to another to get the result instead of using a libgit2 flavor?

Because there are systems without libgit2 library. For example MOSA doesn't support C-style libraries...

Is there a defined interface (API) between GitExtensions UI and backend? If not, why not?

[jcoder76]

For the ease of portability we should do our best to support a managed library back end. As previously mentioned, the native wrapper limits our portability options.
However, libgit2sharp is more likely to be in sync with git development. I'm not sure how far jgit lags or lacks in git features, but a subproject is likely to lag even more.
I am almost condoning another project here or a rewrite of libgit2sharp in pure managed mode. If only there was a way to translate the libgit2 C code to managed as an internal library in an automated way, that would be better. Then all the work on the wrapper code wouldn't be a waste. It may just need tweaking.

[linquize]

Note that libgit2 is GPL. If you automatically convert libgit2 to other languages, the converted library must be GPL.
JGit is EDL not GPL. NGit follows JGit to be EDL.

[sharwell]

@linquize That is not quite correct. The difference lies in the Linking Exception, which you can see at the top of the COPYING file for the libgit2 project. From a licensing perspective, the converted library could be used essentially everywhere the original library can be used.

[linquize]

Does the converted library still have linking exception?

[jcoder76]

Yes. But the libgit2 library wrapper will be linked not contained then. Effectively it would be the same as it is now, only not a C library.

[jbialobr]

Closing as NGit seems to be dead.

[ArsenShnurkov]

awww! anyway we have this place to continue discussion and can reopen it later

[DanRigby]

It should be noted that Visual Studio itself started with a combination of 1 (git.exe) and 2 (libgit2sharp) but has recently moved to just using the stand alone git executable. https://blogs.msdn.microsoft.com/visualstudioalm/2017/03/06/new-git-features-in-visual-studio-2017/

[KindDragon]

We can use libgit2 for some tasks like revision graph in the future