Missing features in git

I've been writing some more git docs, and I came across a few things git does that I'm not sure are desirable.

One thing I noticed is that with ref logs, you've just re-invented the CVS problem of associating history with a name. If you want to rename a branch (say, from "mischacks" to something suitable for publication), do you rename the log or not? It's a less virulent form, but it seems like the same disease.

Another minor quibble: AFAICT, "git checkout -f -m" is meaningless (-f overrides -m), but doesn't complain.

One feature that I noticed is missing, is that there's no easy way to do a "git reset --hard" while doing a "git checkout" style merge.

An example of when you'd want to do this is performing a "git bisect" with a local "#define DEBUG 1" change. Particularly if you hit a non-compiling version and need to back up.

  
The only way to do this currently is somethig like:
        git checkout -b temp HEAD^
        git branch -f bisect temp
        git checkout bisect
        git branch -d temp

or the way git-bisect does it
  
        echo "$rev" > "$GIT_DIR/refs/heads/new-bisect"
        git checkout new-bisect || exit
        mv "$GIT_DIR/refs/heads/new-bisect" "$GIT_DIR/refs/heads/bisect" &&
        GIT_DIR="$GIT_DIR" git-symbolic-ref HEAD refs/heads/bisect
  
Either way, it reserves a second branch name, and seems like a bit of
a hack.  I'm already a bit annoyed that "bisect" is reserved but not
clearly documented as such, and note that the branch name "new-bisect",
which we are switched to temporarily, does not match the pattern
"refs/heads/bisect*" that bisect_start checks for.

The only thing I don't know is if this should be a git-checkout option or a git-reset option. The former shares far more code, but the latter might make more logical sense.

  
Personally, I'd prefer if the requirement that HEAD point to
refs/heads were enforced when checking in rather than checking out.
  
Then you could check out an arbitrary version without any of the annoyance
above; I could "git checkout tags/foo" or even "git checkout deadbeef~3".
I wouldn't be on a current branch (which would necessitate changing
"git branch" output), so HEAD would simply contain an object ID directly
rather than being a symlink/symref.

It's a bit of a PITA auditing the code base to find everywhere affected by changing this invariant, but it doesn't conceptually difficult. Is there anything fundamental that this would break?

The above would make a "-b <newbranch>" option to git-commit more useful, but it's not a half-bad idea as it is. It's just one extra command (git checkout -b newbranch; git commit), but it takes a bit of thinking to realize that "git checkout", which normally modifies the working directory, won't touch your ready-to-be-committed changes in