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

On Wed, 14 Oct 2009, Jeff King wrote:

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

quoted

Nicolas Pitre [off-list ref] writes:

quoted

Can't the user confusion be dealt with through some means other than 
making the tool less flexible?  I don't mind extra help message to be 
displayed after a headless commit is made for example.  But trying to 
make the tool more friendly should perhaps come from better education 
rather than added restrictions.

My thoughts only.

I actually share that but there apparently are people who have given up on
the education route.

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.

People like Dscho have to grow a thicker skin then.  There will _always_ 
be user complaints regardless of how balanced you try to make a UI.

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.

Sure.  That's part of it, and beginners must get over with that 
perception.  Git is a professional tool and not a toy project anymore.  
Like any professional grade tool, there is a greater effort needed from 
beginners before being comfortable with the tool.

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.

Right.  Removing features That _are_ being used sounds a bit backward. 
Just because they happen to be confusing to beginners is not a good 
justification to remove/cripple them IMHO.

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.

Well, New users won't be new forever.  And Git is different from most 
other SCMs.  Eventually that difference is well understood by most 
not-so-new-anymore Git users.  Right now I have to deal with Perforce at 
$work and I find it _terribly_ confusing and obnoxious to use.  So it's 
only a question of getting used to something different.

IMHO this patch proposed by Daniel about the detached head is probably a 
good compromise.  It makes "confusing" operations more verbose to give 
new users a better feeling while keeping the flexibility intact.  And 
increased verbosity is less annoying than decreased flexibility.


Nicolas