Nodeids are unique ids that identify the contents of a file and its position in the project history. For now they are computed using the SHA1 hash function, which generates 160 bits (40 hex digits). If you modify a file, commit the change, and then modify it to restore the original contents, the contents are the same but the history is different, so the file will get a new nodeid. This history-sensitivity is obtained by calculating the nodeid from the concatentation of the parent nodeids with the file's contents, as follows:

nodeid = sha1( min(p1, p2) + max(p1, p2) + contents )

The first version of a file has no parents, so p1 and p2 are both the nullid, which is simply a nodeid of all zeros. For non-merging versions, p1 is the parent and p2 is the nullid. For merging versions, p1 and p2 are both non-null.

Nodeids are typically presented to the user as shortened hex strings, like this:

$ hg id
8d43f8c0b836 tip

The nodeid 00000... is special and is known as the nullid. It serves as the empty root revision. This has the nice property that otherwise unrelated revisions have a common empty ancestor.

Nodeids are used in revlogs.