Jeff King <peff@peff.net> writes:

quoted text
> On Wed, Jan 31, 2007 at 09:59:08AM -0500, Nicolas Pitre wrote:
>
>> Also the warning when moving to a detached head is useful to make the 
>> user aware of what just happened because there is really something 
>> special about such checkout.  It is not meant to frighten users and if 
>> it does so then maybe it should be reworked some more.  But IMHO it is 
>> important that the user be aware of this special state.
>
> What is so special about it? My argument is that it is not really very
> special _until you make commits_. Are there other operations which we
> should be warning people about if they have a detached head?

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.

Imagine "git bisect" did not exist, or was not powerful enough,
and the user was doing it by hand using something other than
"git bisect" to guide him which state to go next, or the user
did not want to use the special "bisect" branch, or some
combination of the above.  You move your detached HEAD around
and finally you are at the commit you are interested in.  You
haven't marked it in some way (perhaps "git tag") yet.  You
haven't made any commit, and the commit is reachable in some
way, but all the work to reach that state will be lost unless
you jot its commit object name down somewhere.

So "until you make commits" is not sufficient, which means that
covering all the way you can make commits isn't, either.



-
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