Re: Missing features in git

[linux@horizon.com]

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