[MonoDevelop] git integration with monodevelop

[Andreas Ericsson]

Michael Hutchinson wrote:
> On Wed, Nov 12, 2008 at 5:22 AM, Andreas Ericsson <ae at op5.se> wrote:
>> Recently, I've started learning C#. More for fun than anything else,
>> but one of the mono core devs sniffed me out and said they've been
>> thinking of porting jgit to C# to get a working IDE integration in
>> monodevelop. Currently, the only option available (with IDE
>> integration anyways) to the poor C# devs is either Microsoft's
>> crappy VSS, or the less crappy but still far from fantastic
>> Subversion.
> 
> I'm glad you're interested :-)
> 
> We do have an interface in MD for integrating VCS providers, and
> although the only existing one is SVN, I believe some users are
> working on bzr and perforce addins. I'd prefer to see git get
> established as the default (D)VCS ...
> 
> Currently, to implement  a VCS provider one needs to subclass
> VersionControlSystem, as demonstrated by the SVN provider:
> http://anonsvn.mono-project.com/viewvc/trunk/monodevelop/main/src/addins/VersionControl/MonoDevelop.VersionControl.Subversion/MonoDevelop.VersionControl.Subversion.addin.xml?view=markup.
> We may need to extend the interfaces in order to expose more
> DVCS-specific features, but I think it's best to find and fix these as
> needed rather than speculatively implementing things.
> 

I'll look into it. One thing I'd love to see is a "bisect" command
from within the IDE. That's one of those things that would make the
first IDE implementing it simply sell itself to hackers and suits
alike. Besides, "bisect", once learned, is such an awesome tool that
coders will start to adapt their workflow just to get full benefit
from it.

>> So in an effort to learn C#, I've decided to play along with this
>> (hopefully with some help from the MonoDevelop team), but it seems
>> to me that the best place to start is the fledgling libgit2 and link
>> that with git-sharp. The primary reason for this is ofcourse that I
>> think it'd be a terrible waste to have yet another from-scratch
>> implementation of git in a new language (ruby, java, C#, C...). The
>> secondary reason is that it would be neat to have more OSS projects
>> use my favourite scm.
> 
> That's actually one of the reasons we'd like a full managed
> implementation --it'd be trivial to include to with cross-platform
> Mono-based apps without worrying about architecture, C dependencies,
> etc. For example, Tomboy could use git to store its notes, so users
> would have a versioned history and better synch/merge. Then, for
> example, you could build a Silverlight version that would have full
> history in local storage.
> 

What's considered "unmanaged"? (remember I'm a C# newbie here). Is it
stuff marked as "unsafe"? If so, there's a whole platoon of stuff to
re-implement, which is quite nuts. Iiuc, a "safe" way of implementing
unmanaged code is to always write to objects passed as parameters in
libgit2, like so:

    int git_commit_get(git_commit *commit, git_oid *oid);

instead of

    git_commit *git_commit_get(git_oid *oid);

as one can let git_commit be a class that gets instantiated and also
gc'd the normal way. libgit just has to make sure not to leak memory
and avoid side-effects, but that's good library design anyways, so
it's not as if C# integration would hurt libgit design.

I really think this would be a better approach that could make the C#
implementation stay on top of new features (such as the up-and-coming
v4 pack) a lot better than writing it from scratch.

libgit2 is intended to be portable to all unices as well as Windows
and Mac OS X, so there's no real problem there

>> Besides, getting something to rely on libgit2 early on is probably
>> the best way to get more people interested in making development of
>> it proceed rapidly.
>>
>> Thoughts anyone?
> 
> I hadn't heard of libgit2 (it looks pretty recent)

It is.

> but it looks
> interesting -- at least stable APIs would no longer be a worry.
> However, I think fully managed is the way to go, from the point of
> view of much easier dependencies (on windows, mac, silverlight and
> older linux distros) and licensing.
> 

But who's going to write (and separately maintain) the 50k or so LoC
that will make up the git core lib in C#? It really is a waste of
resources, imo. Especially since libgit will get a lot of exercise,
whereas the C# code will get that of C#-based integrations only. I
have a feeling this would lead to bugs (or limitations) in the C#
implementation that the git community would be expected to deal with.

-- 
Andreas Ericsson                   andreas.ericsson at op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231