Re: Compatibility between git.git and jgit

[Nicolas Pitre <nico@cam.org>]

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

> 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.

> 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