This is meant for the stable branch

There are definitely repositories in the wild where p1 is nullrev (and p2 is not). It's unusual but expressable so, of course, it happened.

For that matters, there is also case with nullrev != p1 && p1 == p2.

In D5594#83078, @yuja wrote:

I've seen many bugs in the git codebase that were caused by it not
having a null revision and being forced to treat root commits
differently. Mercurial has a null revision and I think it's generally
a bug to treat it differently from other commits in graph algorithms.

I agree with that, but I don't think every non-merge revision (p2 = null)
should be considered a direct child of null revision.

@@ -65,8 +63,6 @@

else:
    parents = cl.parentrevs(r)

Here parents[1] may be nullrev. Is that expected?

for p in parents:

• if p < 0:
• continue

socket.error is a subclass of IOError, which we catch higher up. It

I've seen many bugs in the git codebase that were caused by it not
having a null revision and being forced to treat root commits
differently. Mercurial has a null revision and I think it's generally
a bug to treat it differently from other commits in graph algorithms.

In D5622#83013, @martinvonz wrote:

In D5622#83011, @lothiraldan wrote:

I have the impression that the test changes are due to the previous patch in the stack.

I don't think so. See commit message for why I think they changed.