Use of extra header as storage of metadata breaks hash roundtrip
Created originally on Bitbucket by Andrew Somerville
When pushing hg commits across the gap to git, hg-git’s use of the extra header fields causes the hash produced by the commit to be different than it would have been if the commit had been originally made in a git repo. The reason this matters is that this causes repo histories created by hg-git to be incompatible with those made by tools (e.g. git-remote-hg) which reproduce the history without doing so.
Given that git-remote-hg is quazi official way of accessing hg from git, IMO it’s highly desirable for hg-git and git-remote-hg to be compatible. Clean hash matching is also the common-denominator for any analogous tool.
The dulwich docs warn against using this field, though I think for other reasons: https://www.dulwich.io/docs/api/dulwich.objects.html#dulwich.objects.Commit.extra
Without knowing the full consequences of doing so, I propose using git notes for this purpose instead of extra-headers. AFAIK git notes do not affect the hash and so are a great alternative.
Additionally/alternatively, I’d also propose a compatibility mode which switches between the current behavior and the proposed such that users are not stuck between incompatible version without recourse.
If I have the time, I will produce a PR.