git checkout atomicity?

It was mentioned to me that git checkouts could (like CVS) return inconsistent views of a particular checkin (ie. some of the files from one person’s checkin). I’m guessing this is misinformation, but have only limited git experience to back up this believe. My expectation is based on the fact that even the mechanism for checkout runs counter to this possibility, since we checkout a specific commit, not any specific file. For example,

Create a repo

$ mkdir dummy
$ cd dummy
$ git init
Initialized empty Git repository in /home/myuserid/dummy/.git/

Populate it with some files

$ for i in  a b c d ; do echo $i > $i  d; done
$ git add *
$ git commit -a
$ for i in a b c d ; do echo $i >> $i ; done
$ git commit -a

$ git log a
commit fc1eb954f337e1e7e4ce30b21205f3f1a9542a35
Author: myuserid@mydomain.com <myuserid@mydomain.com>
Date:   Fri Sep 6 13:59:10 2013 -0400

    modified:   a
    modified:   b
    modified:   c
    modified:   d

commit 735e11eae4299d8693c22706a5010283cf4f0506
Author: myuserid@mydomain.com <myuserid@mydomain.com>
Date:   Fri Sep 6 13:58:43 2013 -0400

    new file: a
    new file: b
    new file: c
    new file: d

Now checkout a commit (the older one). See how all the files, not just one (say) of them matches the first commit in this repository

$ git checkout 735e11eae4299d8693c22706a5010283cf4f0506
Note: moving to "735e11eae4299d8693c22706a5010283cf4f0506" which isn't a local branch
If you want to create a new branch from this checkout, you may do so
(now or later) by using -b with the checkout command again. Example:
  git checkout -b <new_branch_name>
HEAD is now at 735e11e... new file: a new file: b new file: c new file: d
$ for i in a b c d ; do cat $i ; done
a
b
c
d

Suppose we checkout the second commit. Now we get all the files from the second commit. It seems to me that “atomicity” is built into the whole concept of g
it checkout:

$ git checkout fc1eb954f337e1e7e4ce30b21205f3f1a9542a35
$ for i in a b c d ; do cat $i ; done
a
a
b
b
c
c
d
d

I’d like to know if it’s possible to label a commit with a more meaningful name than these commit strings that are much like ascii barf.