>>> Another solution would be to be able to put non-head ref in HEAD, >>> but allow to commit only if the prefix is refs/heads/ >> >> That's not a bad idea. Then you can checkout a tag and have >> 'ref: refs/tags/v1.11' in HEAD, which means anyone who puts >> $(git-symbolic-ref) calls into their PS1 will see "refs/tags/v1.11" >> as their current branch, reminding them they are looking at the past. > I agree. This would probably be a good way to do "read-only branches". > > Allowing people to do a "git checkout" on anything committish, but then > not allowing them to commit to that, is probably the right thing to do. > > Together with a nice readable error message from "git commit" (and merge, > and pull - although you might well allow "fetch" to update the thing that > current HEAD points to, though), this would be a lot easier to use for > people who just follow somebody elses branch. This certainly seems like a popular idea. I think the vote is to symlink (symref) to a non-refs/heads/ object if possible, but allow an arbitrary object ID as well. In either case, commits would be forbidden. The only reason I had avoided symlinking before was in case the tag was deleted, but that can be fixed easily enough. (Either make git-tag -d/-f fail, or have it replace the HEAD symref with a raw hex object. Actually, you could do the same with git branch -d. Any opinions?) I can try to write the patch if there are no better volunteers, although it'll take me a lot longer that someone more comfortable with the code. Um.. for example, I'm not sure what the git fetch problem could possibly be. It only updates heads, no? Or are you thinking of the new refs/remotes thing that I'm not familiar with? I'll have to examine the callers of git-symbolic-ref to see what it should do. Return the hex object ID and fail are the obvious possibilities. Note that NOT having any sort of bisect label (and just using HEAD itself as a raw pointer) solves the "git reset --hard" problem; I can "git checkout HEAD^" and have debug hacks preserved. It also removes a paragraph of excuses from some "using git" docs I'm writing. It's a lot easier to explain why you can't commit if you're not on a branch than to explain why you can't not be on a branch. Oh, and as I mentioned, not that "git checkout -b <newbranch>" is exactly painful, but I think a "-b <newbranch>" option to git-commit would be a convenience. (An interesting question is whether it should create the new branch even if there is nothing to. I'm thinking "yes" at the moment, but would be interested in any reasons not to.) - 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