Differences between revisions 2 and 10 (spanning 8 versions)
Revision 2 as of 2008-01-13 12:56:35
Size: 1261
Editor: abuehl
Comment: +Nodeids are used in [:Revlog:revlogs]. Link to SHA info
Revision 10 as of 2014-12-03 01:50:13
Size: 1829
Comment:
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:
Nodeids are unique ids that represent the contents of a file ''and'' its '''Nodeids''' are unique ids that identify the contents of a file ''and'' its
Line 5: Line 5:
[http://en.wikipedia.org/wiki/SHA_hash_functions 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
[[http://en.wikipedia.org/wiki/SHA_hash_functions|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
Line 9: Line 8:
different, so the file will get a new nodeid.  This different, so the file will get a new nodeid. This
Line 11: Line 10:
concatentation of the parent nodeids with the file's contents. 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'' (which, because of sorting, means that the first 20 bytes are the nullid). For merging versions, p1 and p2 are both non-null. Note that p1 and p2 in the function above are in binary, not hex (they are 20 bytes each, leading to a 40 byte prefix).
Line 20: Line 26:
  ''Note: The short-form notation for SHA1 hash values in Mercurial is    ''Note: The short-form notation for SHA1 hash values in Mercurial is
Line 23: Line 29:
  as it is unambiguous (see also ["ChangeSetID"]).''   as it is unambiguous (see also [[ChangeSetID]]).''
Line 26: Line 32:
as the empty root revision. This has the nice property that otherwise unrelated
revisions have a common empty ancestor.
as the empty root [[Revision|revision]]. This has the nice property that otherwise
unrelated revisions have a common empty ancestor.
Line 29: Line 35:
Nodeids are used in [:Revlog:revlogs]. Nodeids are used in [[Revlog|revlogs]].

[[FrenchNodeid|Français]]

Nodeids

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 (which, because of sorting, means that the first 20 bytes are the nullid). For merging versions, p1 and p2 are both non-null. Note that p1 and p2 in the function above are in binary, not hex (they are 20 bytes each, leading to a 40 byte prefix).

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

$ hg id
8d43f8c0b836 tip
  • Note: The short-form notation for SHA1 hash values in Mercurial is the substring of the first 12 characters of the hex string representation of the full SHA1 value. The short form can also be entered in commands, as long as it is unambiguous (see also ChangeSetID).

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.

Français

Nodeid (last edited 2014-12-03 01:50:13 by KyleLippincott)