Re: [PATCH] Detached HEAD (experimental)

["J. Bruce Fields" <bfields@fieldses.org>]

On Tue, Jan 09, 2007 at 01:20:27PM -0800, Junio C Hamano wrote:
> 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.