Shawn O. Pearce wrote:
Junio C Hamano <gitster@xxxxxxxxx> 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?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html