Comment 10 for bug 1372149

Hi Susan,

See this thread, which sprung up on the Git list after I added support for extra commit headers in Dulwich: http://git.661346.n2.nabble.com/extra-headers-in-commit-objects-td4508608.html

The consensus among Git developers seems to be that defining new header fields should be left up to the Git developers. What hg-git is doing goes against that.

bzr-git doesn't completely adhere to the guidelines in that thread either since it doesn't just drop unknown fields. There are good reasons it can't just ignore headers it doesn't know about though. See my earlier comments for a more thorough explanation:

Throwing an error when unknown fields are encountered is intended behaviour. bzr-git can't just drop unknown metadata since that makes it impossible to reserialize the original Git objects later. Reserializing is necessary since the original git objects are used as delta bases.

bzr-git could store all unknown headers in an extra metadata field. We don't do this since it means we can't change the mapping of any unknown headers later without breaking all existing bzr-git users. Instead, since git commit header extensions are so rare, we require explicit support for them in bzr-git.

Dulwich is used for parsing and creating Git objects in bzr-git; bzr-git doesn't use Dulwich to store data, it uses native Bazaar objects.

Is your project itself maintained in Git or in Mercurial? If it is in Mercurial, you could disable the setting of extra headers in hg-git or alternatively run a cronjob somewhere that uses hg-fastexport and bzr-fastimport to create a bzr branch from a mercurial branch.