git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: extra headers in commit objects

From
Shawn O. Pearce <spearce@spearce.org>
Date
Feb 3, 2010, 22:39 UTC
Message-ID
<20100203223901.GJ14799@spearce.org>
In-Reply-To
<1265230702.7429.54.camel@ganieda>
Jelmer Vernooij <jelmer@samba.org> wrote:
Show 9 quoted lines
> On Wed, 2010-02-03 at 09:40 -0800, Shawn O. Pearce wrote:
> > 
> > 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.
OK.
> 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.
I probably should have CC'd you in from the beginning, sorry.

Its true, this is a high-volume list. But we don't see much, if anything, about Dulwich here. Yet I for one like to see discussion about other implementations here, to some extent, so its easier to make sure everyone is staying close to the C implementation's reference standard.

Show 5 quoted lines
> 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.
Yes, apparently Scott didn't quite represent things accurately.
Oh well, it seems its been raised now, and beaten to death.
 
> 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.

That's true, and I'm glad you have made that change to Dulwich. It is a good bug fix to skip over headers you don't recognize.

But, its a new incompatible feature to support writing extra headers.
> If this is indeed a misunderstanding, I'll happily make this
> datastructure with custom headers read-only.
Yes.  Please see the other messages in this thread, especially from
Nico and Junio.  Setting other headers is not a good idea, and you
shouldn't encourage it in Dulwich by making an API available.
 
Show 9 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.
I'm glad to hear that.
See above about keeping discussion related to other Git implementations
here.  We're happy to help explain something that is perhaps vague or
poorly specified.  Not everyone has the answer right away, but usually
the list fills in everything.
 
Show 7 quoted lines
> > 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. 
OK, I haven't actually looked at the Dulwich client code...  so I
don't know what its current state is.
 
> 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.

OK, then you may be interested in some of the patches my friend Dave worked up (he said he was going to send them to you). Dave discovered the server wasn't playing nice with C git, and asked me for some protocol help to get it going again.

I'm glad its only an issue of neglect (lack of time) and not something else that has caused it to be incompatible.

-- 
Shawn.
Previous: Nicolas Pitre
Message 20 of 20 in “extra headers in commit objects”
  1. Shawn O. PearceFeb 3, 2010
  2. Nicolas PitreFeb 3, 2010
  3. demerphqFeb 3, 2010
  4. Shawn O. PearceFeb 3, 2010
  5. demerphqFeb 3, 2010
  6. Junio C HamanoFeb 3, 2010
  7. Shawn O. PearceFeb 3, 2010
  8. Junio C HamanoFeb 4, 2010
  9. A Large Angry SCMFeb 4, 2010
  10. Petr BaudisFeb 3, 2010
  11. demerphqFeb 3, 2010
  12. Shawn O. PearceFeb 3, 2010
  13. Nicolas PitreFeb 3, 2010
  14. Sverre RabbelierFeb 3, 2010
  15. Scott ChaconFeb 3, 2010
  16. Shawn O. PearceFeb 3, 2010
  17. Mike HommeyFeb 4, 2010
  18. Jelmer VernooijFeb 3, 2010
  19. Nicolas PitreFeb 3, 2010
  20. Shawn O. PearceFeb 3, 2010

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.