update: fix performance of updating to null commit

Summary:
When updating to the null commit, the logic that computes the update
distance was broken. The null commit is pre-resolved to -1, which when passed to
a revset raw gets resolved as the tip commit. In large repositories this can
take a long time and use a lot of memory, since it's computing the difference
between tip and null.

Let's fix it to not pass the raw rev number, and also to handle the case of a 0
distance update.

Reviewed By: quark-zju

Differential Revision: D23358402

fbshipit-source-id: 3b0a1fe1bbcb07effba4d0ab2c092e66bdc02e67

eden/scm/edenscm/mercurial/merge.py

@@ -2097,13 +2097,19 @@ def _logupdatedistance(ui, repo, node, branchmerge):
         return
 
     try:
+        # The passed in node might actually be a rev, and if it's -1, that
+        # doesn't play nicely with revsets later because it resolve to the tip
+        # commit.
+        node = repo[node].node()
         revdistance = abs(repo["."].rev() - repo[node].rev())
-        if revdistance >= 100000:
+        if revdistance == 0:
+            distance = 0
+        elif revdistance >= 100000:
             # Calculating real distance is too slow.
             # Use an approximate.
             distance = ((revdistance + 500) / 1000) * 1000
         else:
-            distance = len(repo.revs("(%s %% .) + (. %% %s)", node, node))
+            distance = len(repo.revs("(%n %% .) + (. %% %n)", node, node))
         repo.ui.log("update_size", update_distance=distance)
     except Exception:
         # error may happen like: RepoLookupError: unknown revision '-1'