{"thread":{"id":"19156","subject":"Re: Compatibility between git.git and jgit","startedAt":"2009-05-02T11:00:05Z","lastAt":"2009-05-02T11:00:05Z","messageCount":1,"participants":["Mark Struberg"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"112873","messageId":"806445.80395.qm@web27803.mail.ukl.yahoo.com","threadId":"19156","inReplyTo":null,"subject":"Re: Compatibility between git.git and jgit","fromName":"Mark Struberg","fromEmail":"struberg@yahoo.de","sentAt":"2009-05-02T11:00:05Z","receivedAt":"2009-05-02T11:00:05Z","isPatch":false,"sender":{"key":"struberg@yahoo.de","avatar":"https://gravatar.com/avatar/119742c3e8dbc8db35a92bdff0581aec8d364d415f770e60431cba262daa974f?d=mp&s=160"},"body":"\nAs for compatibility between JGIT and GIT:\n\nWe (the Apache maven-scm team with Shawn supporting us (thanks again for patiently answering my sometimes stupid questions)) are currently working on a JGIT SCM provider for maven. The commandline git-provider already works pretty ok since more than a year now and once we have the JGIT version too. all this gets tested automatically via our TCK suite.\n\nThe TCK suite is pretty high-level, but at least all the fundamental stuff is then guaranteed to work for both implementations.\n\nOne step on our road is to further 'abstract' the current jgit-core library and introduce a SimpleRepository which basically contains the most important git commands as Java calls (e.g. addRemote, fetch, ... ) [1]. So after having this it should be really easy to side-by-side compare the .git/* of e.g. git-clone uri vs SimpleRepository.clone(uri)\n\n\nLieGrue,\nstrub\n\n[1] http://github.com/sonatype/JGit/ branch struberg\n--- Shawn O. Pearce <spearce@spearce.org> schrieb am Sa, 2.5.2009:\n\n> Von: Shawn O. Pearce <spearce@spearce.org>\n> Betreff: Re: Compatibility between git.git and jgit\n> An: \"Nicolas Pitre\" <nico@cam.org>\n> CC: \"Junio C Hamano\" <gitster@pobox.com>, git@vger.kernel.org\n> Datum: Samstag, 2. Mai 2009, 3:59\n> Nicolas Pitre <nico@cam.org>\n> wrote:\n> > On Fri, 1 May 2009, Shawn O. Pearce wrote:\n> > \n> > > On an unrelated note, someone asked me recently,\n> how do we ensure\n> > > compatibility in implementations between git.git\n> and jgit?\n> > \n> > Well... this is not exactly easy.  As I said in\n> the past \n> > (http://marc.info/?l=git&m=121035043412788&w=2), I think\n> that the C \n> > version must remain the reference with regards to\n> protocols and on-disk \n> > data structures.\n> \n> I agree fully.\n> \n> > If people go wild with JGit and start making changes \n> > to data structures then it simply won't be Git\n> compatible anymore and \n> > the user base will get fragmented.\n> \n> Agree.  We may see some prototyping happen in JGit\n> first on some\n> topics, and JGit may even support something earlier than\n> git.git,\n> e.g JGit has an amazon-s3:// transport that git.git doesn't\n> have.\n> But it also isn't widely used.\n> \n> > A formal compatibility test suite would imply that\n> every Git \n> > reimplementation should be compatible with the\n> reference C version.  \n> > You could add some tests in your test suite which are\n> performed in \n> > parallel using JGit and the C git, and make sure that\n> the produced \n> > results are identical, etc.\n> \n> Yea, and to some extent we try to do that already in JGit,\n> but our\n> tests aren't complete enough in that area.\n>  \n> > But to which extent should the C version remain\n> backward compatible with \n> > other implementations?  Let's suppose a future\n> protocol extension is \n> > made and old unsuspecting C clients work just fine but\n> some other \n> > implementation crashes with it?\n> \n> This is what I think scares both myself and the folks that\n> have\n> recently asked me about compatibility.\n> \n> If JGit gets a broader user base, and suddenly it stops\n> working\n> against a newer C git-daemon because of a protocol change,\n> those\n> users are going to be pissed.  Its no worse than the\n> \"github can't\n> ever upgrade past 1.6.1\" issue we had not too long ago.\n> \n> I think we're doing better these days about embedding file\n> format\n> version numbers into files (e.g. pack idx v2) to help alert\n> older\n> clients that the format is different.  But we also\n> have a something\n> of a history of looking for \"holes\" in older C git parsers\n> in\n> order to wedge in new features where we didn't plan for\n> them in\n> the first place.  E.g. the protocol capability slots\n> we have now.\n> \n> I think that as reimplementations become more popular, we\n> need to\n> rely less on extending things by exploiting parser quirks\n> in older\n> C git.git code, and rely more on at least explicit version\n> markers\n> that everyone can work with.\n> \n> > And the reference implementation cannot be held back\n> because \n> > of bugs in all alternative implementations.\n> \n> I agree.  A bug is a bug.  But I'd really like to\n> get away from the\n> trend where we exploit bugs in older C git.git\n> implementations to\n> add new functionality, because maybe JGit doesn't have that\n> same\n> bug and will fall flat on its face with that exploit.\n> \n> > As long as they're futzing^Wdeveloping on top of Jgit\n> then \n> > interoperability shouldn't be at risk.  If people\n> would start adding new \n> > object types and pack formats and the like without\n> obtaining a consensus \n> > with people around the C version then I might get\n> extremely worried (and \n> > pissed) though.\n> \n> That's why JGit is BSD, so everyone can use the one f'king\n> library\n> and not risk fragmenting the Java market further.\n> \n> But yea, I'd be really pissed too if someone hacked up JGit\n> and made\n> it incompatible with anything else.  Its a risk that\n> the liberal\n> BSD license permits.\n> \n> I'm really sort of hoping that the development momentum\n> around\n> git.git and JGit trying to keep up will keep them coming\n> back\n> to the canonical JGit for updates, forcing them to give\n> back any\n> hacks^Wimprovements they have made.  If the\n> improvements really are\n> worthwhile, they can be easily ported over to C before they\n> become\n> widely used in JGit.\n>  \n> > One defensive approach we could adopt is to use a\n> capability slot to \n> > identify the software version of each peer involved in\n> the network \n> > communication.  The advantage would be for a\n> later Git version to avoid \n> > doing some things that are known to break with client\n> X or Y.  Of course \n> > even such a scheme can be abused and misused, like on\n> some web sites if \n> > you don't have the \"right\" browser, leading some of\n> them to allow faking \n> > the User-Agent string, etc.  But maybe the\n> upsides are more important \n> > than the downsides.  This doesn't help with\n> on-disk interoperability, \n> > but this is probably less important than communication\n> interoperability.\n> \n> Blargh.  I'm with you about the whole User-Agent\n> mess.\n> \n> Asking clients and servers to identify with implementation\n> and\n> version markers might be useful for analysis of\n> who-is-using-what,\n> but I don't think its a good way to negotiate between the\n> peers of\n> what functionality to enable or disable, or what bug\n> workarounds\n> to use.  Reminds me of the Apache hack during output\n> to work around\n> an HTTP header parsing bug in Netscape 2 when the \"\\r\\n\"\n> pair was\n> exactly at byte 256 in the stream.  *shudder*\n> \n> \n> FWIW, an EGit user recently complained that some random Git\n> hosting\n> site they were using couldn't work with EGit, but EGit\n> worked fine\n> with other sites, e.g. GitHub.  Apparently this site's\n> SSH forced command\n> filter script didn't like EGit asking for \"git upload-pack\n> 'path.git'\".\n> \n> Its not strictly a Git protocol issue, how the client\n> launches\n> the remote process over SSH, but this random hosting site\n> was\n> apparently relying on C git's current calling convention\n> of\n> \"git-upload-pack 'path.git'\".\n> \n> Long story short, I claimed it was the hosting site's\n> bug.  :-)\n> \n> -- \n> Shawn.\n> --\n> To unsubscribe from this list: send the line \"unsubscribe\n> git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n> \n\n\n      \n"}]}