Re: Obscure error/warning/information message from git pull

[Eli Zaretskii]

> From: David Kastrup <address@hidden>
> Date: Sun, 16 Nov 2014 17:16:34 +0100
> 
> It's not that different from Emacs itself where a lot of defaults and
> options and commands are "user-friendly" but, in contrast to other
> "user-friendly" editors, when trying to solve real-world tasks on your
> own you are likely going to run into complexity and Elisp leaking in
> your face.  So it's not all that rare when demonstrating the user
> friendliness of Emacs, there are the occasional 10 seconds where you
> have to ask your audience to look away for a moment.
> 
> Git workflows with the default commands are rather close to the
> "plumbing" and need to refer to it at times.  As a result, it's fairly
> easy to run into "look away for a minute" territory.  So "I don't want
> to learn about internals" may be even less successful in the long run
> than "I don't want to learn about Elisp" is with Emacs, and there is
> less of a tradition with Git over Emacs of having others around who have
> built turnkey applications for your workflows.

I was talking about newbies starting to use Git.  Newbies, in Emacs
and Git alike, start with copying cookbook-like recipes without deep
understanding of the internals.  Later they learn more.  But even
before that, they need some mental model of what they are doing.  That
model does not need to be exact as far as details go, but it must
grasp the main concepts.

I'm saying that brainwashing newbies with implementation details, and
especially insisting on the point that Git is unlike anything else
they are familiar with, is counter-productive.  It just raises one
more high obstacle for them to negotiate, unnecessarily.  Let them get
to that in their due time.  Meanwhile, if they can successfully apply
familiar concepts, let them.