Re: Missing features in git

[Petr Baudis <pasky@suse.cz>]

On Tue, Nov 14, 2006 at 07:40:30PM CET, Linus Torvalds wrote:
> On Tue, 14 Nov 2006, Shawn Pearce wrote:
> 
> > Jakub Narebski <jnareb@gmail.com> 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