From: J. Bruce Fields <bfields@fieldses.org>
Date: Thu, 11 Jan 2007 04:31:01 GMT
Subject: Re: [PATCH] Detached HEAD (experimental)
Message-ID: <20070111043101.GB29214@fieldses.org>
In-Reply-To: <7vslei764u.fsf@assigned-by-dhcp.cox.net>

On Wed, Jan 10, 2007 at 04:34:57PM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
> 
> > On Tue, Jan 09, 2007 at 03:46:32PM -0800, Linus Torvalds wrote:
> >
> >> I would suggest a solution:
> >> 
> >>  - git checkout will refuse to switch AWAY from a detached head unless the 
> >>    SHA1 of the detached head exactly matches some other branch.
> >
> > What about
> >
> >   git checkout HEAD~20
> >
> > I agree that checking out tags will be more common, but it feels like we
> > are discouraging this usage by presenting spurious warning messages.
> 
> Once the user knows what HEAD~20 means, I think it is safe to
> assume that the user knows what the branches are.

I'm interested of course in making life easy for project admins when
they need to tell testers how to get code to test out of git.  It'll be
nice to able to say:

	"Install git, then run
	git clone git://ourproject.com/ourproject.git
	cd ourproject
	git checkout <version you want>
	"

Instead of having to say

	"Install git, then run
	git clone git://ourproject.com/ourproject.git
	cd ourproject
	git checkout -b FOO <version you want>

	Then if you later need to check out another version, run
	git reset --hard <other version>
	"

I suppose <version you want> will typically be either some tagged
release or the latest head.  But it's not that farfetched to imagine
asking someone to test version 01997b4....

> "git checkout master" will barf and suggests the user possible
> common exits; "checkout -f" if there is nothing of value,
> "checkout -b <branch>" or if they want to build on the current
> state.

That should make it easy enough, though, I guess.

--b.