Troubleshooting SHA1 Failures with Mercurial Repositories

[Paul Boddie]

On Saturday, 13 June 2020 22:53:19 CEST Augie Fackler wrote:
> 
> More nuanced than that, actually. The censor page is only relevant if you’ve
> used censor, which you’d know.

I wasn't sure about this, due to the phrasing which, in various cases, sounds 
as if it is referencing general Mercurial design principles and behaviours. 
Plus scary wording that I thought might apply in my own situation, such as...

  "hg verify" will fail due to the hash mismatch as well.

> As I said, if you’ve got a repo passing `hg verify` then it’s definitely
> _not_ corrupt. The metadata ordering can change and that’ll (by nature of a
> content-addressed system) change the node ID, but the content is the same.
> Eg
> 
> {‘branch’: ‘foo’, ‘rebase_src’: ’some_hash_here’}
> {‘rebase_src’: ’some_hash_here’, ‘branch’: ‘foo’}
> 
> are the same key-vale pairs, but in different order. If they are stored in
> hg in different orders, you’ll get different hashes, and if you use `hg
> convert` on an older repository the ordering of key/value pairs in various
> metadata regions will get normalized, which changes hashes.

So, I imagine that this normalisation might explain why some repositories 
diverge from their newly-converted form very early in their histories, well 
before I can believe that this problem with digest generation might have 
arisen.

[...]

> Ah. Convert is a useful tool for recovering from corrupt repos, but it
> doesn’t sound like you’ve got any.

This is reassuring to learn. I imagine that there is little to be gained from 
recomputing any faulty digests, given that their role, faulty or otherwise, is 
to provide convenient but opaque references that give the history its 
structure.

Thanks once again for following up!

Paul

P.S. I did a "long" test with smartctl which yielded no errors on the disk 
where my repositories were stored, so I am still inclined to think that the 
disk itself is not the cause of these problems.