On Tue, Jan 09, 2007 at 01:43:16PM -0800, Carl Worth wrote:
quoted text
> 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.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html