extra headers in commit objects

["Shawn O. Pearce" <spearce@spearce.org>]

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@pobox.com> 1265176189 -0800
  committer Junio C Hamano <gitster@pobox.com> 1265176189 -0800
  bug 18389
  url http://example.com/some/mailing/list/post
  message-id <gitster-182819131@gitster.computer>

  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.