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

On Wed, Oct 14, 2009 at 05:56:52PM -0700, Junio C Hamano wrote:

I am personally undecided on this issue (my "this is the best option" was the best of "a -f switch to commit, an 'expert' config option', or a session-based option to commit").

But we really seem to have reached an impasse with how to proceed with git ui.

People like Dscho are fed up with user complaints about parts of git that can be unfriendly to new users. And I can understand that. There _is_ a perception that git is hard for beginners to use, and I don't think that perception is entirely without merit. We expect the user to understand the basic concepts of git, like history graphs, named refs versus detached heads, tracking refs, the index, etc.

At the same time, I think that is what many of us _like_ about git. It is based around simple and powerful concepts, and it doesn't get in your way when you want to use those concepts in a powerful and flexible manner. And I can understand resistance to making those features hard or inconvenient to access; detached HEADs were invented for a reason, and we want to use them.

So what is the right way to mediate between those desires? We have tried or suggested several options, including:

  1. Educate users. Keep exposing them to the concepts, but make
     messages more clear. Improve documentation. This is largely the
     route taken with the index. Has it worked? I think there is still a
     perception among new users that the index is confusing.

  2. Use configuration options to differentiate behavior. This comes in
     the form of the sometimes-requested "expert/beginner mode" option.
     But it can also mean a config option for a specific behavior. The
     argument against it I have seen is that it can make git
     unpredictable for new versus old users. An old-timer helping a new
     person is more out-of-touch with what the new person's setup will
     do (which hurts when sitting at their terminal or when giving them
     advice online).

  3. Make a new porcelain interface that wraps the git plumbing. We have
     seen some examples of this. Obviously cogito was the first, and it
     has fallen by the wayside as people moved towards core git. That
     may be an artifact of its timing, though, as core git was a rapidly
     moving target, and power users wanted to use the new features. More
     recently we've had 'eg'. I don't know how many people are using it,
     but it is certainly not discussed on this list much. There are also
     GUIs wrapping git. I think these are subject to the same argument
     as (2), but even more so. An entirely new interface like 'eg' is
     really splitting the user base. As a git old-timer, I can keep up
     with what newbie options might impact git's behavior. But I haven't
     a clue how to do anything in 'eg'.

  4. Hide potentially dangerous behavior behind "-f" or similar options,
     or make it even more inaccessible. We have done this with some
     obviously dangerous cases, like "push -f" or "checkout -f", which
     can throw away data. But I think in cases where the behavior is
     simply confusing and not dangerous, we tend not to do this (at
     least I couldn't think of any examples off the top of my head). The
     obvious argument against it is that it inconveniences more
     experienced users. Dscho advocated "the good of the many" versus
     "the good of the few". And I can see some logic in that. At the
     same time, open source is about scratching itches. Is anyone really
     interested in doing something that makes our own itch worse?
     Everytime you use it, won't you be thinking about scratching?

So I don't know what the solution is. And maybe this is just useless pontificating. But I feel like we have this discussion over and over, every few months, about a different feature. I wish there were some way to fix that.

Out of ideas, -Peff