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 tempor 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
