On Tue, Jan 09, 2007 at 01:20:27PM -0800, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> 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. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html