Re: extra headers in commit objects

From: Jelmer Vernooij <jelmer@samba.org>
Date: Feb 3, 2010, 20:58 UTC
Message-ID: <1265230702.7429.54.camel@ganieda>
In-Reply-To: <20100203174041.GC14799@spearce.org>

Hi Shawn,

On Wed, 2010-02-03 at 09:40 -0800, Shawn O. Pearce wrote:

Show 18 quoted lines

> 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...)

Show 10 quoted lines

> 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".

If you have concerns like this in the future, please don't hesitate to contact me directly. I don't follow the git list because it's a high-volume list where pretty much all traffic is irrelevant to me. The only reason I became aware of this thread was because Sverre CC'ed me.

> Uhm.

Originally I was under the impression that custom headers would break (by reading the C Git source code) and so Dulwich made that assumption, but after hearing from several people (among whom Scott, see his reply) at Linux.Conf.Au that custom headers could be added and were ignored by C git I made this change.

Since Dulwich would blow up when it encountered custom headers that might be set by other Git implements and since (as I understand) C git ignores unknown headers, I called this a bug fix. This change made it possible to deal with custom headers whenever they would appear *and* allowed users of the Dulwich API to set custom headers.

(FWIW I haven't actually seen anybody setting custom headers)

If this is indeed a misunderstanding, I'll happily make this datastructure with custom headers read-only.

[...]

Show 5 quoted lines

> 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.

So does Dulwich. I've fixed issues in the compatibility with C Git when I've noticed them or have been made aware of them. Any incompatibilities are the result of ignorance on my part rather than malicious intent.

[...]

> 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?  :-(

I've been using Dulwich's client to talk to C Git servers for ages and haven't seen issues. I would appreciate hearing about incompatibilities.

If you're talking about the server side - we know it's broken, at least dul-daemon. Nobody (except for API changes) has really cared about it since John Carr originally hacked it up. I'd be surprised if it even works with the Dulwich client.

Cheers,

Jelmer