Changeset = commit = revision, although by slang (or “abuse of language”, like mathematicians would say) a revision can also be a revision number.
A revision number is a sequentially increasing number assigned to commits in the order that they arrive to this repo. A hash is a hash.
Revision numbers can be shorter for smaller repos, although not for Mozilla. They have another benefit, though: they’re usually semantic. Almost always, revision 1 was created much farther in the past than revision 1000. If there is no branching, revision 41 is the parent of revision 42.
The equivalent way to say HEAD in Mercurial is “.”, probably with analogy with “current directory” in Unix, although here it means more “current commit” or “the commit I’m standing on” (more precisely, “the parent of the working directory”).
They change. They’re basically just counting numbers, one assigned to each node of the graph. It doesn’t really make sense for to talk to you about “node 77” in my graph, because you probably have a different graph.
If you browse hg through a web interface, you’ll see everything is identified using the longer hashes.
The sequential numbers just make certain operations a little easier. I might run hg log | more in one terminal, then hg log -p -r NUM in another. I can type 100 easier than 16ced1a76ccb and I don’t have to worry about guessing shortest unique prefix.
The displayed changeset ID is a “short-form identifier” of the full hash digest. 12 digits is long enough that you wouldn’t expect to see a duplicate in a repository with fewer than a billion commits or so. If you want the full hash you can get it using the “node” template for “hg log”.
The act of creating a changeset is called a commit or checkin. A changeset includes the actual changes to the files and some meta information. The meta information in a changeset includes:
the nodeid of its manifest
the list of changed files
information about who made the change (the “committer”), why (“comments”) and when (date/time, timezone)
the name of the branch (“default”, if omitted or not set)
The nodeid is the long form of the changeset hash, and is determined based on the node IDs of the changeset’s parent(s), which is what makes a mercurial repository a merkle graph - each ID depends on the SHA hash of all of the ancestors of changeset corresponding to that ID.
Typically only the first 12 digits (48bits) are displayed for readability, but it’s a full 40 digit (160bit) SHA1 under the hood. You can use hg log -T {node} to see it.
There is a risk of collision, but the odds are astronomically low with the full hash, and even negligible with the shortened 48bit prefix.
There’s so much I want to add to this…
Changeset = commit = revision, although by slang (or “abuse of language”, like mathematicians would say) a revision can also be a revision number.
A revision number is a sequentially increasing number assigned to commits in the order that they arrive to this repo. A hash is a hash.
Revision numbers can be shorter for smaller repos, although not for Mozilla. They have another benefit, though: they’re usually semantic. Almost always, revision 1 was created much farther in the past than revision 1000. If there is no branching, revision 41 is the parent of revision 42.
The equivalent way to say
HEADin Mercurial is “.”, probably with analogy with “current directory” in Unix, although here it means more “current commit” or “the commit I’m standing on” (more precisely, “the parent of the working directory”).just curious: how are revision numbers chose given the distributed nature of development?
They change. They’re basically just counting numbers, one assigned to each node of the graph. It doesn’t really make sense for to talk to you about “node 77” in my graph, because you probably have a different graph.
If you browse hg through a web interface, you’ll see everything is identified using the longer hashes.
The sequential numbers just make certain operations a little easier. I might run
hg log | morein one terminal, thenhg log -p -r NUMin another. I can type 100 easier than 16ced1a76ccb and I don’t have to worry about guessing shortest unique prefix.Better than me pronouncing it “hag”…
aich gee
…
Am I missing something? Isn’t this changeset ID 12 digits long?
Also, how does
hgprevent duplicate changeset ID’s? Are they generated based on a time?The displayed changeset ID is a “short-form identifier” of the full hash digest. 12 digits is long enough that you wouldn’t expect to see a duplicate in a repository with fewer than a billion commits or so. If you want the full hash you can get it using the “node” template for “hg log”.
There is a bunch of metadata that goes into calculating the changeset ID, from this page in the mercurial wiki:
The nodeid is the long form of the changeset hash, and is determined based on the node IDs of the changeset’s parent(s), which is what makes a mercurial repository a merkle graph - each ID depends on the SHA hash of all of the ancestors of changeset corresponding to that ID.
Typically only the first 12 digits (48bits) are displayed for readability, but it’s a full 40 digit (160bit) SHA1 under the hood. You can use
hg log -T {node}to see it.There is a risk of collision, but the odds are astronomically low with the full hash, and even negligible with the shortened 48bit prefix.