On Wed, Jul 16, 2008 at 06:21:02PM +0100, Johannes Schindelin wrote:
>
> I had the pleasure of introducing Git to a few users in the last months
> and in my opinion, restricting myself to teaching them these commands
> first helped tremendously:
>
> - clone, pull, status, add, commit, push, log
Yes, it is a good list, and I think it is very important at the
beginning to limit the number commands to 7-8, otherwise many users
may be confused. And, of course, it is better to stay away from all
command-line options at first...
>
> All of these were presented without options, to keep things simple.
>
> In particular, I refrained from giving them the "-a" option to commit.
> That seemed to help incredibly with their embracing the index as a natural
> concept (which it is).
Most things that we call as "natural" is those that we got used. Once,
you got used to it, it seems very natural, and the index is not
something that is really difficult to learn, but I don't think that
everyone may understand it fully. Some may use Git for many months and
only then suddenly discover that "git diff" does not show all
uncommitted changes, but only changes between their working directory
and the index. It may sound strange, but it happens.
> Now, it makes me really, really sad that Git has a reputation of being
> complicated, but I regularly hear from _my_ users that they do not
> understand how that came about.
I think this reputation is largely due to people who open Git user
manual, read about >100 commands, were horrified and stopped learning.
Git is a powerful and very flexible tool, thus to use it to its fullest
you may really need to learn a lot, but it does not mean that you can
use it and be much more productive than with other VCS knowing only a
small fraction of all options. Thus if you can explain to users in terms
that they understood and connect that with their workflow, users may
find Git easier to use than SVN...
>
> Am I the only one who deems teaching plumbing to users ("I like it raw!
> So I teach it the same way!") harmful?
There is only one thing that seems to be true about teaching Git (or
anything else) -- there is no single method that works equally well
for anyone. Having said so, I must admit that teaching plumbing will
be probably not a good idea for most users, yet there are some who
prefer bottom-up approach. Some users will prefer to connect Git
functionality to their particular needs and solving some practical
tasks that they do day in, day out, while others may prefer to start
with more abstract things like DAG, structure of data, etc... For
the later users, when you explained these basic things, you do not
have to explain commands at all. They may occasionally ask you
something like: git grep works fine for me when I need to find
something in arbitrary file at some particular revision, but how
about finding something in a particular file at arbitrary revision?
Then you say -- look at git log, it should have the grep option. It
is usually all explanations that you need to provide for them. The
rest, they will quickly pick up on their own. Yet, majority users are
not like that. They seem to prefer to start with specific use cases
and only basic porcelain commands... So, I agree with you here.
Dmitry
--
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
