On Tue, 22 Jul 2008, Johan Herland wrote:

quoted text
> On Tuesday 22 July 2008, Scott Chacon wrote:
>> If anyone has any tips on how they think git should be taught, issues
>> they are asked a lot, problems newbies tend to have, something they
>> wish there were a screencast for or was better documented, etc -
>> please do contact me so I can incorporate it.
>
> You should at least take a look at this thread:
>
> http://thread.gmane.org/gmane.comp.version-control.git/88698
>
> (even though it goes off-topic after a while...)
>
>> If anyone has any tips on how they think git should be taught...
>
> It seems there are primarily two ways to teach Git:
>
> 1. Top-down: Start with simple use cases and commands. Teach people a
> minimal, but necessary set of porcelain commands to get them started. Stay
> _far_ away from plumbing commands and most of the command options.
>
> 2. Bottom-up: Start with how Git structures the data. Talk about blobs,
> trees, commits, refs, how everything is connected, and how various Git
> commands query and manipulate this structure. This _may_ involve a fair
> amount of plumbing commands, especially when discovering how the more
> complicated high-level commands manipulate the structure.
>
> Some people seem to prefer the first approach, other people prefer the other
> approach. Both paths lead to enlightenment ;). In many cases a bit of both
> may be useful. HOWEVER, I think it is _very_ important to keep in mind that
> these are two _different_ approaches, and the contexts in which they are
> taught should be kept separate. I would almost suggest splitting your
> website down the middle and make the difference between top-down and
> bottom-up immediately visible with, say, a different background color, or
> something else that immediately tells the user what "track" they are
> following...

possibly a combination of the two?

under the covers the git data-structures are pretty simple and explaining 
them (and the minimal tools to manipulate them) isn't that bad.

what gets ugly is when you then try to use the plumbing to do the 
non-trivial things.

so how about an optional 'under the covers' primer, covering just the 
trivial plumbing, then the high-level minimal introduction with a link on 
each of the commands as they are introduced (so that a person can dig into 
deeper detail if they want to, possibly including 'up until version X 
this command was implemented by the following script'), followed by links 
to sample work-flows and a full dive into the plumbing (because at this 
point the person should know enough to get by, now they need reference 
material and examples more then a tutorial).

ideally this would let people dive as deep as they are comfortable with, or 
skim the explanation for the functionality

I think one reason the 'plumbing first' approach gets a bad rap is that 
it's so easy to get caught up into how clever you can get with the 
plumbing. it's like teaching someone programming by spending a day 
introducing them to concepts and language syntax, and then giving them the 
entries in the obfuscated C contests as examples of how someone can use 
them to get work done, but skipping any mention of libc or other standard 
libraries.

on the other hand, teaching only porcelain is like teaching them <insert 
high-level *th generation buzzword language> without teaching any concept 
of what they computer is doing under the covers, they can work, and even 
get useful work done, but they will be limited on how effective they can 
be.


you can't be a great programmer until you can understand both levels, the 
under-the-covers 'plumbing' and the high level libraries of the 
'porcelain', trying to ignore either will limit you.

David Lang

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html