view tests/remotefilelog-getflogheads.py @ 50741:bca4037306da stable

rust-revlog: fix incorrect results with NULL_NODE prefixes

In case a short hash is a prefix of `NULL_NODE`, the correct revision
number lookup is `NULL_REVISION` only if there is no match in the nodemap.
Indeed, if there is a single nodemap match, then it is an ambiguity with the
always matching `NULL_NODE`.

Before this change, using the Mercurial development repository as a testbed (it
has public changesets with node ID starting with `0005` and `0009`), this is
what `rhg` did (plain `hg` provided for reference)

```
$ rust/target/debug/rhg cat -r 000 README
README: no such file in rev 000000000000
$ hg cat -r 000 README
abort: ambiguous revision identifier: 000
```

Here is the expected output for `rhg` on ambiguous prefixes (again, before
this change):

```
$ rust/target/debug/rhg cat -r 0001 README
abort: ambiguous revision identifier: 0001
```

The test provided by 8c29af0f6d6e in `test-rhg.t` could become flaky with
this change, unless all hashes are fixed. We expect reviewers to be more
sure about that than we are.

from mercurial.i18n import _
from mercurial import (
    hg,
    registrar,
)
from mercurial.utils import (
    urlutil,
)

cmdtable = {}
command = registrar.command(cmdtable)


@command(b'getflogheads', [], b'path')
def getflogheads(ui, repo, path):
    """
    Extension printing a remotefilelog's heads

    Used for testing purpose
    """

    dest = urlutil.get_unique_pull_path_obj(b'getflogheads', ui)
    peer = hg.peer(repo, {}, dest)

    try:
        flogheads = peer.x_rfl_getflogheads(path)
    finally:
        peer.close()

    if flogheads:
        for head in flogheads:
            ui.write(head + b'\n')
    else:
        ui.write(_(b'EMPTY\n'))