I think you (and others in the thread) are forgetting that

moving to a particular state by resetting can create a state

that you may want to keep a pointer to, but you do not have any

existing ref.  That's one of the reasons why we do not merely

check if the detached HEAD is not reachable from any of the

existing refs when coming back.  Instead, we check and warn if

the detached HEAD does not exactly match one of the existing

refs.
Imagine "git bisect" did not exist, or was not powerful enough,

and the user was doing it by hand using something other than

"git bisect" to guide him which state to go next, or the user

did not want to use the special "bisect" branch, or some

combination of the above.  You move your detached HEAD around

and finally you are at the commit you are interested in.  You

haven't marked it in some way (perhaps "git tag") yet.  You

haven't made any commit, and the commit is reachable in some

way, but all the work to reach that state will be lost unless

you jot its commit object name down somewhere.
So "until you make commits" is not sufficient, which means that

covering all the way you can make commits isn't, either.
-

Is that an important distinction?  The way the user got there was by

manually specifying the SHA-1 shash of the commit to git-checkout.  So

if the user could get there once, the user could get there again a

second time.  Just because we don't have a name to that precise commit

inside the git system doesn't necessary mean the user can't get back
My personal belief is that covering all the way you can make commits

is where you want to be putting the check.  If I say something like
git checkout f00b51b8
There's nothing dangerous about that statement.  To argue that this is

dangerous and the git needs to warn me because I might not be able to

get back to it seems silly.  Of _course_ I can get back there; the

same way I got here in the first place --- By simply saying, "git

checkout f00b51b8" again!
And if I tell a user that they should try out a particular version of

the code, issueing a scary message right then there is pointless if

they are only going to be doing a read-only browse of the tree, is

just a Bad Thing.  The best place to warn them really is when they

modify the tree.
Otherwise, we'll be educating users to use the -f flag, or telling

users to "ignore the warning, git's being silly", neither of which is

desirable.
						- Ted

-

If you mean grep 'git checkout|git reset' perhaps.  After

checking out a specific commit (because the user was told about

the commit out-of-band, say, via e-mail), the user can still
I do not think anybody is arguing that particular checkout is

dangerous.  The warning message is about the fact that your HEAD

is now detached, which might not have been what you intended

(and you will later get a real warning when you do a really

dangerous thing, which is "to come back and lose your point").
-