Re: extra headers in commit objects

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

Scott Chacon <schacon@gmail.com> wrote:
> On Wed, Feb 3, 2010 at 9:40 AM, Shawn O. Pearce <spearce@spearce.org> wrote:
> > Today I came across this "bug fix" [1,2] in Dulwich, which is
> > claiming to be a pure-Python implementation of Git.
> >
> > 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".
> 
> At the risk of pissing you off for the second time in as many days,
> this is entirely my fault.

Apparently, s**t happens is a good phrase.  One I need to learn.

> I was having a beer with Jelmer in Wellington a few weeks ago

And... beer doesn't promote clear thinking.

All is forgiven.  As is yesterday's remark about not telling me
sooner about a JGit bug.  You really didn't do anything bad, I
just woke up on the wrong side of the bed the past couple of days,
and sort of went off...

Sorry.  :-\

> Anyhow, I was saying that _technically_ you can artificially write
> extra headers into the commit object (though at the time Dulwich
> didn't support reading them because of how it parsed commit objects -
> I believe it would actually explode if it saw something it didn't
> expect).  I said I was still going to keep the metadata in my
> implementation in the message, but he was very interested in hiding
> his in the commit headers.

Yea, everyone wants to hide that extra metadata.  I never get why.
Even in SVN.  Why wouldn't I want to see the bug(s) fixed by
a commit?  Difference of opinion.  I also happen to prefer the
color blue.  Dammit, everyone should prefer blue.

> To my defense, we (you and I, Shawn)
> talked about this at the GitTogether this year and you and a few
> others told me that CGit would not blow up but would just ignore them,
> which is fine for his purposes.  I certainly did not get the
> impression from that short discussion that this was something to be
> absolutely avoided, but rather that it just wasn't really encouraged
> or explicitly supported.

Sorry.  I've held this same opinion as Junio and Nico have expressed
in this thread, that although we ignore extra headers, its only to
leave us an escape hatch in case we add something like "encoding"
in the future.  Adding encoding was almost a nightmare because we
didn't have that escape hatch.

I also hold the opinion that the C implementation is correct,
and everyone else is wrong.  Even JGit.  Unless its a bug in the
C implementation, in which case the bug fix is correct.  :-)

Which in this case means, if the C implementation doesn't give
the user plumbing to do something (aside from using git mkobject),
you really should think twice before doing it.

So I apologize if I gave you the wrong impression at the GitTogether.
I claim stupidity as my only defense.

> Sorry.  So, for future reference, though CGit _can_ handle it, don't?

C Git won't choke if there are extra headers.

But we _really_ don't want them.  And C Git won't be writing any new
headers anytime soon.  I think we're more likely to shift the entire
hashing scheme to SHA-512 or something before we add a new header.

-- 
Shawn.