On Thu, 14 May 2009, Scott Chacon wrote: > On Tue, May 12, 2009 at 4:34 PM, Shawn O. Pearce <spearce@xxxxxxxxxxx> wrote: >> Jakub Narebski <jnareb@xxxxxxxxx> wrote: >>> We have now proliferation of different (re)implementations of git: >>> JGit in Java, Dulwich in Python, Grit in Ruby; and there are other >>> planned: git# / managed git in C# (GSoC Mono project), ObjectiveGit >>> in Objective-C (for iPhone IIRC). At some time they would reach >>> the point (or reached it already) of implementing git-daemon... >>> but currently the documentation of git protocol is lacking. >> >> Well, lets see... [...] >> ObjectGit - Scott Chacon, again, a GitHub folk. Though he has >> expressed interest in moving to JGit or libgit2 where/when possible. > > Actually, all of this work has moved to CocoaGit, which is much > farther along than ObjectiveGit ever was. Although I would love to > use libgit2 when it gets that far, this was for Mac/iPhone native > client work which JGit would not be helpful for. Could you give URL for homepage or announcement (if it exists), and for git repository / web interface page for CocoaGit? It isn't present on http://git.or.cz/gitwiki/InterfacesFrontendsAndTools which tries to be clearinghouse and list all significant git tools... but which is probably hopelessly out of date now (unfortunately). > >> >> Dulwich - off in its own world and not even trying to match basic >> protocol rules by just watching what happens when you telnet to a >> git port. No clue how that's going to fair. > > Oddly enough, I'm in Dulwich land too. I've been working on a > Mercurial plugin that will provide a two way lossless bridge for Hg to > be able to push and pull to/from a Git server. I'm assuming here that the bridge has to remember somehow about the info which cannot be represented in other SCM (like octopus merges, or tag objects, or tagging non-commits in Git; like I guess 'rename tracking' information in Mercurial) to be it truly two-way... > I've fixed some of the > issues I've found with the client side work and both pushes and pulls > will work now. (I did turn off 'thin-pack' capability announcement, > since you're correct that it simply was not properly implemented). > > If we're going to round out the list, I've also worked on an > ActionScript partial implementation, but it never got to the packfile > level, and some of the Erlang guys are interested in writing at least > a partial Erlang implementation too, which I may get involved in at > some point. Well, with yet another implementation it is even more important to have good technical documentation of file formats and network protocols. BTW. if I remember correctly there were some hobbyist one-person (single-developer) implementations of git in Haskell and in Lisp or Scheme... > > It seems like if anyone would do what you're asking, it's probably me. > In the next few weeks, I do what I can to fix up the remainder of the > Dulwich code as part of my hg-git work. I'm also working with Shawn > on the Apress book, where I was going to try to document much of this > information, perhaps I could try writing an RFC as an appendix or > something - then that will force him to spend time correcting > everything I got wrong :) At least that might be a good starting > point - I'm unfamiliar with the actual RFC process, so I'll research > that a bit today. I don't mind writing it, I think it would be really > really useful to have, I just am unfamiliar with the process. I don't think RFC _process_ is something to worry about; in the future perhaps (just like Atom Publishing protocol was submitted to IETF). I was thinking about _format_ used in RFC (BNF-like specification, specific semantic for 'MUST' etc. like in RFC2119). Although any format (more or less formal) would be better that none. Thank you very much for your offer! -- Jakub Narebski Poland -- 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