Am I correct that core C developers are still under the opinion that extra headers in a commit object aren't encouraged? That is, we shouldn't see something like this made-up example: $ git cat-file commit HEAD tree e0fb24d872e2daa1507ea5879e1cdce5c0da9902 parent ec0865178ad6d8dab9ccd82b07bc3f3dae20542a parent 89d61592bddda4dfcb90314be9e06479f712bb7f author Junio C Hamano <gitster@xxxxxxxxx> 1265176189 -0800 committer Junio C Hamano <gitster@xxxxxxxxx> 1265176189 -0800 bug 18389 url http://example.com/some/mailing/list/post message-id <gitster-182819131@xxxxxxxxxxxxxxxx> Merge git://repo.or.cz/git-gui into next (Sorry Junio for picking on your latest next merge...) Today I came across this "bug fix" [1,2] in Dulwich, which is claiming to be a pure-Python implementation of Git. [1] http://git.samba.org/?p=jelmer/dulwich.git;a=commit;h=bc8d73f1146afba8828a7dadbb4320f592cddcab [2] http://git.samba.org/?p=jelmer/dulwich.git;a=commitdiff;h=bc8d73f1146afba8828a7dadbb4320f592cddcab;hp=4e50426fb72e6c9259feecbba5bfcf053af62335 I haven't spoken with Jelmer Vernooij directly about it, but after some indirect email through a 3rd party, it seems he might be under the impression that this really is a bug in Dulwich, because "other git implementations do it". Uhm. I thought the canonical reference implementation was C Git (aka git-core), as maintained by Junio Hamano, and the object formats, core data structures, and network protocols were fairly well documented between the Git Community Book and the Documentation/technical/ directory. The only other widely used Git implementation that I know of is JGit. It sure as hell doesn't do this, and it sure as hell isn't what I would call the reference implementation for Git... and that project is my own baby. Yes, there are many other Git implementations. But I thought nearly all of them were toys, and none of them were even close to serving the kind of production volume that JGit serves, and JGit isn't even considered a production library by most. Yet JGit always tries to conform to whatever standard is set by the C implementation. Basically, aside from having a pretty horrible morning thus far, and being in a really bad mood, I'm starting to get a bit worried about the proliferation of Git implementations, and what the notion of the standard network protocol and file formats is. We're starting to see a fork in the basic protocols happen. Hell, Dulwich 0.4.1 isn't even capable of speaking over the network to C Git, but it does talk to itself, so its valid, right? :-( $ PYTHONPATH=`pwd` ./bin/dul-daemon . & $ git clone git://localhost/.git Initialized empty Git repository in /usr/local/google/users/sop/tmp/localhost/.git/ fetch-pack: protocol error: bad band #78 fatal: early EOF fatal: index-pack failed Fortunately a friend of mine is spending some time trying to patch it up... trying to get it back in compliance with the C reference implementation. At the end of the day, is it a bug that C git doesn't support working with extra commit headers? IMHO, no, because, we've rejected these in the past, and its not part of the Git standard. And other implementations shouldn't be trying to sell it that way. </rather-pissed-off-rant> -- Shawn. -- 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