Pulkit Goyal <7895pulkit@gmail.com> [Mon, 15 Feb 2021 17:08:18 +0530] rev 46694
debugtagscache: verify that filenode is correct
Previous patch from Matt demonstrates that `debugtagscache` does not warn about
filenode being unknown which can be caused by a corrupted cache.
We start by showing that it's an unknown node.
Differential Revision: https://phab.mercurial-scm.org/D10015
Matt Harbison <matt_harbison@yahoo.com> [Thu, 24 Dec 2020 12:23:46 -0500] rev 46693
tests: demonstrate a case where a corrupt tag cache causes an abort
I happened to hit this trying to cover other cases around valid vs missing
entries. I have no idea if this is something that could occur more naturally
(similar to how a missing file node in `hgtagsfnodes1` can occur after a strip).
There is a test just above this added in f5a7cf0adb12 mentioning it "overwrites
the junk", though that tests truncation instead of actual garbage.
But since this is just a cache, it probably shouldn't abort with a cryptic
message like this. The two options I see both have downsides- either rebuild
the cache (and potentially take a long time), or hint to the user to run a debug
command.
Differential Revision: https://phab.mercurial-scm.org/D9812
Pulkit Goyal <7895pulkit@gmail.com> [Tue, 16 Feb 2021 20:38:14 +0530] rev 46692
debugcommands: prevent using `is False`
I was touching this code in a future patch and marmoute warned about usage of
`is False` here.
Quoting marmoute:
```
"is False" is going to check if the object you have the very same object in
memory than the one Python allocated for False (in practice 0)
This will "mostly work" on cpython because of implementation details, but
is semantically wrong and can start breaking unexpectedly
```
Differential Revision: https://phab.mercurial-scm.org/D10014