Re: Compatibility between git.git and jgit

From: Nicolas Pitre <nico@cam.org>
Date: May 2, 2009, 01:39 UTC
Message-ID: <alpine.LFD.2.00.0905012032590.6741@xanadu.home>
In-Reply-To: <20090502000123.GF23604@spearce.org>

On Fri, 1 May 2009, Shawn O. Pearce wrote:

Show 9 quoted lines

> On an unrelated note, someone asked me recently, how do we ensure
> compatibility in implementations between git.git and jgit?
> 
> There isn't exactly a great notion of "a Git implementation can do
> X, Y, Z, and never does Q".  So its not like we have a compability
> test suite to run between the two systems.
> 
> JGit is really starting to gain some traction in the open source
> world.

Well... this is not exactly easy. As I said in the past (http://marc.info/?l=git&m=121035043412788&w=2), I think that the C version must remain the reference with regards to protocols and on-disk data structures. If people go wild with JGit and start making changes to data structures then it simply won't be Git compatible anymore and the user base will get fragmented. A good way to prevent this is for people interested in making git compatible tools to monitor and interact on the git mailing list, however if we look at the results from some past GSOC projects we must conclude that not everyone is giving enough consideration to that.

A formal compatibility test suite would imply that every Git reimplementation should be compatible with the reference C version. You could add some tests in your test suite which are performed in parallel using JGit and the C git, and make sure that the produced results are identical, etc.

But to which extent should the C version remain backward compatible with other implementations? Let's suppose a future protocol extension is made and old unsuspecting C clients work just fine but some other implementation crashes with it? The more you have reimplementations of Git, the greater is the possibility for one of them to be flawed and buggier in one way or another but happened to just work with older C git versions. And the reference implementation cannot be held back because of bugs in all alternative implementations.

Show 7 quoted lines

> A lot of folks at Eclipse are really excited about being able to
> ship a BSD licensed VCS.  Some of the Maven folks are really excited
> about being able to link JGit up to Apache MINA SSHD and have a 100%
> pure Java server solution for Git, that doesn't require native OS
> authentication systems.  Gerrit Code Review relies entirely on it,
> and some folks within Google are now using Gerrit Code Review and
> its embedded MINA SSHD/JGit server as their only Git daemon.

As long as they're futzing^Wdeveloping on top of Jgit then interoperability shouldn't be at risk. If people would start adding new object types and pack formats and the like without obtaining a consensus with people around the C version then I might get extremely worried (and pissed) though.

> Thus far, our compatibility story with git.git has been, "it should
> work, uh, we think, because Shawn understands git reasonably well,
> and wrote some of JGit, so uh, yea....".  :-)

If that works, and as I know you I'm sure that works great, then maybe this should just continue that way for as long as it is workable.

> But I think in another 12 months we'll be seeing people running
> only JGit in many contexts, making compatibility between the two
> implementations somewhat more important than it has been in the past.

One defensive approach we could adopt is to use a capability slot to identify the software version of each peer involved in the network communication. The advantage would be for a later Git version to avoid doing some things that are known to break with client X or Y. Of course even such a scheme can be abused and misused, like on some web sites if you don't have the "right" browser, leading some of them to allow faking the User-Agent string, etc. But maybe the upsides are more important than the downsides. This doesn't help with on-disk interoperability, but this is probably less important than communication interoperability.

Nicolas