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. Frankly, I don't understand why so much effort is being put toward allowing these "fragile commits" to be made in the first place. Why not require users to name the branch before creating any commits, just as has always been the case? To me, the only real advantage to the new "detached head" stuff is simply making it easier to checkout previous state without having to name a new branch precisely _because_ the user has not intent to commit anything. If the user is going to commit something, then the user should be able to come up with a name for the branch. But, whatever, if allowing fragile commits is seen as important by those doing the work, who am I to complain about that? I'd just ask that the following not be made slow: git checkout commit-from-beginning-of-time git checkout master Thanks to the index, and the simplicity of what "git checkout" means, checkout has always been blisteringly fast. All the talk of doing reachability analysis scares me from a performance point of view, (particularly when the _interesting_ cases (to me) of checkouts to non-branches never need this anyway---since no commits will be made). Thanks, -Carl
Attachment:
pgpHnIYwFFlsP.pgp
Description: PGP signature