Detached just means that your HEAD is a commit, not a ref. There is no particular reason for git-commit to care if a commit is pointed to by a branch, some other sort of ref, is reachable from a commit that is pointed to by a branch or other sort of ref, or detached from everything at all. If you read the code, it is doing the same thing in either case, only differentiating between them to print more useful messages for the users benefit and make sure the user is doing what they really want to do in situations that may be destructive (without falling back on reflog). They really are the same thing.
They're only the same thing at a fundamental level, just like eventually all a computer is doing is moving bits around and all data is a bit stream. This ignores that hey are not treated as the same thing from the UI point of view. If they were, they would not require a lecture to understand how to recover a commit made on a detached HEAD, a lecture that git provides.
They are treated as the same thing at the UI level, hence your complaint. If they were treated as unrelated concepts then they would not both be serviced by git-checkout, despite sharing an underlying implementation.
They are the same thing both in implementation and UI.
The various consequences of detached commits and what happens when you try to modify the working tree when there are uncommitted changes are both concepts that permeate all of git. Handling these things in a graceful manner does not somehow mean that checking out branches or commits are fundamentally different concepts.
If you want an example of muddled UI, git-checkout -b is an infinitely better example. Creating a branch is conceptually unrelated to checking out a branch; git-checkout just provides the -b flag for convenience because typically you want to check out the branch after creating it. It would likely make more sense to provide a --checkout flag of some sort with git-branch, as creating the branch is the primary operation and checking it out is just a secondary convenience. That is a decent complaint.
If this is the sort of thing honestly that bothers you, then just make a git-changebranch alias for git-checkout, pretend that git-checkout can't do branches even though it can do arbitrary commits, and move on with your life.
> they would not require a lecture to understand how to recover a commit made on a detached HEAD, a lecture that git provides.
The only real difference here compared to Mercurial is that Mercurial doesn't issue a warning/lecture... In both cases you will have to know the changeset (or revision number in Mercurial) to get back to that anonomous branch (unless it's tip, but tip has its own issues). Git providing a warning for this is fair imho, as Git garbage collects anonomous branches. That, however, does not change the fact that checking out a random commit and a branch are the same thing in UI and implementation.
