From: A Large Angry SCM Date: Sat, 02 May 2009 01:14:06 GMT Subject: Re: Compatibility between git.git and jgit Message-ID: <49FB9E5E.30504@gmail.com> In-Reply-To: <20090502000123.GF23604@spearce.org> Shawn O. Pearce wrote: > Junio C Hamano wrote: >> The code looks correct, I am reasonably sure updated server-client >> combination would work fine, and use of the capability mechanism means >> other combinations like old pusher and new receiver, and/or new pusher and >> old receiver, should be also Ok. >> >> I see Shawn did the same to jgit. > > 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. > > 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. > > 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....". :-) > > 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. > [A non-answer to this implied question] Usually one of the implementations is declared "the reference implementation". [And another question] Hasn't this issue come up before in the mailing list?