On Wed, 14 Oct 2009, Jeff King wrote: > On Wed, Oct 14, 2009 at 05:56:52PM -0700, Junio C Hamano wrote: > > > Nicolas Pitre <nico@xxxxxxxxxxx> writes: > > > > > 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html