On Tue, Jan 09, 2007 at 01:43:16PM -0800, Carl Worth wrote: > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html