[kstenerud]

Think of the change ID as a "symbolic name", as opposed to the commit ID which identifies a particular snapshot.

As you amend a commit, it creates a new commit ID each time. Only the commit ID of the most recent amendment is in your final graph. All the old ones are orphaned for garbage collection.

The change ID never changes as you make amendments (because you're still working on the same change), and this change ID will always be in the graph. So you can refer to the change ID (which doesn't change) instead of the commit ID (which changes with every amendment).

Another way to think of it would be akin to filenames vs inodes in a filesystem (it's not 100% the same, but the concept should help you visualize). If you delete a file and create another one with the same name, its filename will be the same, but its inode number will be different because it's technically a different file. The old inode gets marked deleted so that it can be reaped somehow. If you make a symbolic link to the file, you'll always get the intended one (because a symbolic link refers to a path). If you make a hard link to the file, you'll get an outdated file after something replaces it (because a hard link refers to an inode).