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

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 16, 2009, 02:56 UTC
Message-ID: <7vvdigxczv.fsf@alter.siamese.dyndns.org>
In-Reply-To: <alpine.DEB.1.00.0910160357370.4985@pacific.mpi-cbg.de>

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.

Show 5 quoted lines

> 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.