Re: [PATCH] Detached HEAD (experimental)

From: J. Bruce Fields <bfields@fieldses.org>
Date: Jan 9, 2007, 21:31 UTC
Message-ID: <20070109213117.GB25012@fieldses.org>
In-Reply-To: <7virffkick.fsf@assigned-by-dhcp.cox.net>

On Tue, Jan 09, 2007 at 01:20:27PM -0800, Junio C Hamano wrote:

Show 16 quoted lines

> Jeff King <peff@peff.net> writes:
> 
> > For example, with what's in next now, I can do this:
> >
> >   git checkout v1.4.0
> >   hack hack hack
> >   git commit -m -a 'some changes which will never be seen again'
> >   git checkout v1.2.0
> >
> > I thought the _point_ of the safety valve was not to lose those changes.
> 
> Fair enough.
> 
> We could always do the check upon "git checkout" from a detached
> HEAD state, whether it takes you back on some existing branch or
> leaves your HEAD still detached.

Stupid question: why can't checkout do something like this?

	if we're currently not on a branch, fail if .git/PREV
		doesn't point to the same commit as .git/HEAD.

	if we're checking out a non-branch, store its SHA1 into
		.git/PREV.

So the user gets a warning (overrideable with some kind of --force option) if they do a checkout when the HEAD isn't exactly what they last checked out. Then

	git checkout master
	git checkout v1.4.0
	git checkout v1.2.0
	git checkout master

all works without complaints, but the example above gives a warning at the "git checkout v1.2.0" point.

--b.