Two things are going on. First, git revisions are revisions of the whole file tree. In contrast, I believe cvs and svn give separate revision numbers to the individual files. So in cvs or svn, the "tag" operation goes out and attaches, e.g., "stable-pre-new-spec" to file1 version 1.0.3, file 2 version 1.0.2, file3 version 2.0, file 4 version 1.3.7, etc. And then when you want to fetch using that tag, the system goes and finds all the pieces with that tag. In git, the one revision already is about the whole set, tagging just gives another name to it.
Second-- and this applies to many cm systems including cvs and svn-- git gives the same name to a state and the difference. Git calls this combined thing a commit. So you ask about the version and it shows you a diff between that and the immediately previous state. In git, the commit id is actually a checksum of the whole saved tree contents; it's just conventional to show you the golden spike.
In git you can tag a commit or create a branch from it any time after you created it.