On Tue, Nov 14, 2006 at 07:40:30PM CET, Linus Torvalds wrote: > On Tue, 14 Nov 2006, Shawn Pearce wrote: > > > Jakub Narebski <jnareb@xxxxxxxxx> wrote: > > > Dnia wtorek 14. listopada 2006 18:36, Karl Hasselström napisa?: > > > > > > > > For example, we could skip the "bisect" branch, since > > > > you aren't supposed to commit to that anyway. > > > > > > Well, to have "branch" to which you could not commit, just put ref > > > outside refs/heads. > > > > > > 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. There's been a brief discussion on a related topic in http://news.gmane.org/find-root.php?message_id=%3cPine.LNX.4.58.0507120938240.17536%40g5.osdl.org%3e (apparently the Linus-has-another-totally-awesome-idea kind (no irony (*))). Before, Cogito did basically what's proposed above to permit again: storing a random sha1 in the HEAD when it is seeked away to some historical commit. It switched to using a temporary branch for this purpose, but I'm not sure about the Linus' reasoning that "in order for a "git checkout" to not get confused and possibly throwing a cogito temporary head away ..." which has been apparently clear to me back then. :-( > 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. So, the basic relaxation is that "again after a year, HEAD does not have to be a ref at all". > 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. Hmm, so that there would be something like refs/tracking/master as an alternative to refs/heads/master? I'm not really sure if it is a good idea. On one hand, you can relax my favorite fastforward restrictions on those tracking branches, but I think the net worth is negative since you will have to burden new users with yet another concept of "readonly branches", tell them things like "either do git clone --no-tracking or the first time you will want to commit something locally, create a 'head' using git checkout -b master HEAD" (you are already on a "master" branch but it's a different "master", you know?) etc. (*) You never are ironical about Linus, the Chuck Norris of CS. (And a hero, too!) -- Petr "Pasky the Wow Pruit Igoe is Awesome Too!" Baudis Stuff: http://pasky.or.cz/ #!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj $/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1 lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/) - 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