Theodore Tso wrote: > On Wed, Jan 31, 2007 at 12:20:33PM -0800, Junio C Hamano wrote: >> I think you (and others in the thread) are forgetting that >> moving to a particular state by resetting can create a state >> that you may want to keep a pointer to, but you do not have any >> existing ref. That's one of the reasons why we do not merely >> check if the detached HEAD is not reachable from any of the >> existing refs when coming back. Instead, we check and warn if >> the detached HEAD does not exactly match one of the existing >> refs. > > Is that an important distinction? The way the user got there was by > manually specifying the SHA-1 shash of the commit to git-checkout. So > if the user could get there once, the user could get there again a > second time. Just because we don't have a name to that precise commit > inside the git system doesn't necessary mean the user can't get back > there. In fact, the user probably could via "history | grep 'git > checkout'". Have you read further? git-bisect could (and probably should) use detached HEAD instead of special 'bisect' branch. Doing bisection can be hard work (checking if commit is good or bad might take time) and we don't want to lose it. Besides, history has finite length, and you could get to the state not only via "git checkout", but also via "git reset --hard". Reflog for detached HEAD would help in this. -- Jakub Narebski Warsaw, Poland ShadeHawk on #git - 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