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
this case.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html