Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was

[Junio C Hamano <gitster@pobox.com>]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> You are trying to educate the users to use the double-clutch.  Rather than 
> making the double-clutch obsolete.

I do not quite get your double-clutch rhetoric, in the sense that I do not
think it has anything analogous in the topic of detached HEAD we have been
discussing.

Didn't we discuss possible solutions to make sure that you do not have to
detach HEAD and lose commits by coming back without saving them?  I would
consider that corresponds to inventing automatic (iow, making sure that
sightseeing can be done without having to worry about accidentally
committing on that state and later losing them).  Obviously, you would
need to cover cases other than we have discussed (e.g. if "rebase -i"
detaches, it needs to allow "commit", "commit --amend", and "reset --soft
HEAD^", but you probably would not want to allow "checkout" to switch to
another branch).  Thinking things through so that we can fill in all these
details is a tedious and hard work, but I would say it would be worth it.
In the ideal world, if you do not have to (nor want to) use the detached
HEAD feature, you do not have to.

But that is entirely different from saying "I do not need to use detached
HEAD, I cannot explain it to my users. Let's make it unusable, iow, I give
up".  Unfortunately that is the impression I am getting from your whining.

If you have been advocating for something else, and you share the goal of
helping users by e.g. making it unnecessary to worry about accidentally
committing on that state and later losing them, you would need to do a
better job explaining yourself.

> Just recently, I had a user request (a very valid one, mind you) where the 
> user does not want to provide a commit message, and wants to just commit 
> all the current changes.  In that particular case, it is very sensible to 
> ask for these things.  It is something utterly simple to ask for. Yet, it 
> is utterly hard with Git, especially if I have to explain it.

I suspect the above is another example of your needing to do a better job
explaining yourself here, but from "just commit all the changes without
saying message", my knee-jerk reaction is "git commit -a -m 'no message'".

You would need to justify why -m 'no message' does not fit the bill better
than just saying "is very sensible to ask for these things", as I highly
suspect that I misunderstood what "these things" are in your five lines to
come up with that "solution" that you are now going to explain why that is
not what the end user wanted.  And in this case, I do not think it is that
me being disconnected from the real world, but that your explanation is
insufficient.