On Thu, 01 Feb 2007 13:06:34 -0800, Junio C Hamano wrote:
> The error message you quoted is given when your head is detached
> and you tried the regular "checkout an existing branch" -- which
> will lose where your detached HEAD currently is.
I think the problem with this is that git tells the user so little
information, ("may lose your changes"). What changes? Is that dirty
state? Some commits? Hmm... have I committed anything? Why can't git
be sure about what this operation is going to do?
I think a really useful message would be something like:
You are not on any branch so switching to branch 'foo'
will cause the following commits to be lost:
ba531642 A commit headline here...
b1189118 Another commit headline here...
Refusing to checkout 'foo'.
Didn't a bunch of work get committed to make the reachability analysis
feasible to generate a message like this?
If there are no commits that would become dangling, then the checkout
should just proceed. As for the concern about losing a pointer to some
"valuable" state that will still technically be reachable, but might
be hard to get back, why not just print a message along the lines of:
Leaving commit 7b1509f4 to checkout 'foo'.
(or just depend on the HEAD reflog).
-Carl
PS. If nothing else gets changed in the current message, please
reconsider the current wording of:
Leaving your HEAD detached; not switching to branch 'foo'.
Think: Wow, I had heard that git might help me shoot myself in the
foot, but I never though I might behead myself with it.
It would probably work to just reword that as:
Not switching to branch 'foo'.
Attachment:
pgprBvzJuEYul.pgp
Description: PGP signature