Re: git annoyances

* Daniel Barkalow <barkalow@iabervon.org> wrote:

well, current git got to /home/mingo/linux-2.6-x86.git/ which is a local path. (it is printing it in the error message above) So i think it was rather unambiguous what i meant and Git knew about it, right?

but even if it _was_ ambiguous, i think tools should generally default to a minimal amount of hassle for new users and should try to pick reasonable "action" versus any "inaction". (as long as the behavior is still deterministic and reasonable even to the long-time user)

but more importantly, i think this whole problem area has to be handled with a slightly different kind of mindset than other, more technical aspects of Git.

Humans, and in particular males, when they see or learn new things, are very emotion-driven. The first 1-2 minutes (often just the first few seconds) have a very strong influence on whether that person 'likes' a new topic, tool or gizmo he is checking out - or not. Males often think of themselves as being objective when shopping new items - while in reality more than 90% of their purchasing decisions are emotion-driven and it's all set and done in the first 10 seconds of visual contact. (this ration is far higher than for females)

Command-line tools like Git are at heavy natural disadvantage compared to say GUI tools because the "first impression" is so minimalistic and relatively unremarkable. A GUI can get people hooked by making the first 10% look easy just via old-fashioned, dishonest visual deception.

so basically for 90% of the new users, we've got 2-3 shots or we lose their "sympathy". Starting with an error message is bad. Being uninformative about what happened is bad. Making the user wait without signalling why he is waiting is bad. Etc. etc. I think this experience of mine was a reasonable simulation of a first-time user reaction (by virtue of me having forgotten certain Git details).

And the moment a negative first-time impression has settled in it's very hard to overcome that emotional mindset and barrier. People might still think "Git is quirky" even if we do all things perfectly from that point on. The same holds for the other direction: a positive first-time impression is harder to destroy, even if it turns out to be not that simple later on.

A tool's reaction back to first-time users is like a decision tree: every negative reaction, every error message, every unreasonable wait, every uninformative output is a way for the user to exit our ecosystem and to never discover the true strengths of Git.

So i really think that maintaining this aspect of Git and in essence Huffman-optimizing the interface and the learning curve for first-time Git users is perhaps the most important thing. Especially since some users like me will often re-learn Git details that they use rarely.

Getting these details right is _extremely hard_, because the people who are capable of fixing these details have long forgotten the first-time annoyances they had! (if they had any - often developers are statistically lucky and never hit any pitfalls.)

It's doubly hard because Git developers work on Git exactly because they _like_ it, so one's own positive experience has to be contrasted to the prospect of negative first-time experience.

It's triple hard because it might also mean changing some things that have been done in Git since the start of the project. A negative experience that isnt some technical problem in the strict sense - it's an emotional thing that is much harder to define and much harder to agree on and improve.

So i think it's really hard mentally - and i'm positively surprised by the many constructive and positive reactions that my mail generated.

Improving this area is perhaps even harder than adding new functionality 
- but i think it's a key and extremely strategic aspect of Git, because 
it affects the very heart of the Git project: it maximizes the influx of 
new users (who also include future Git developers btw.) and minimizes 
outflux of existing users.

	Ingo