Re: extra headers in commit objects

From: Scott Chacon <schacon@gmail.com>
Date: Feb 3, 2010, 19:58 UTC
Message-ID: <d411cc4a1002031158k3e50db30l3f7d73d49e3dad23@mail.gmail.com>
In-Reply-To: <20100203174041.GC14799@spearce.org>

Hey,

On Wed, Feb 3, 2010 at 9:40 AM, Shawn O. Pearce <spearce@spearce.org> wrote:

Show 7 quoted lines

> 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. I was having a beer with Jelmer in Wellington a few weeks ago during LinuxConf.au and we were talking about the difficulties in storing metadata having to do with cross-vcs migrations - specifically his work with an bzr-git bridge and mine with the hg-git project. He was noting that I kept all my metadata about original Hg commits in Git as formatted text in the commit message, which is pretty uggo (especially with the amount of sometimes inconsistent denormalization of data Hg does on commit, explicitly recording renames and manifests and whatnot).

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

Oddly enough, this whole thing basically came up because we were noting that you can hide extra data in Hg changesets, but it's a ridiculous hack involving adding it after a null byte in the timestamp field, much like we do in adding the capabilities after the first ref in the negotiation phase of the tranfer protocol. I was just casually saying, "yeah, you can actually technically do that a lot cleaner in Git"...

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

thanks, Scott