Re: [PATCH] Detached HEAD (experimental)

From: J. Bruce Fields <bfields@fieldses.org>
Date: Jan 9, 2007, 21:53 UTC
Message-ID: <20070109215343.GC25012@fieldses.org>
In-Reply-To: <87zm8ryiyz.wl%cworth@cworth.org>

On Tue, Jan 09, 2007 at 01:43:16PM -0800, Carl Worth wrote:

Show 19 quoted lines

> On Tue, 9 Jan 2007 16:31:17 -0500, "J. Bruce Fields" wrote:
> > > >   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.
> ...
> > 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.
> 
> I would guess the problem is that this would still cause warnings even
> if the user had since given a name (created a branch) for the commits
> originally made to the dangling head.

I think as long as we provided a special exception for a case like "git checkout -b":

	git checkout v1.4.0
	hack hack hack
	git commit -m -a 'some changes'
	git checkout -b new-changes

and also provide a way out (--force-checkout-losing-current-head) for people that really know what they're doing, that should be more than enough to handle that sort of case.

Because, I agree, the point is to make easy what 90% of users will probably do, at least on the first encounter with git--download project X, checkout version Y, build--and making checkouts on detached commits convenient seems a lower priority.

--b.