Re: improving the CG

[Colin Campbell]

Trevor Daniels wrote:
> Carl Sorensen wrote Monday, December 28, 2009 5:25 AM
>
> > Oh, I agree that it would have the added benefit of a greater 
> > audience, but
> > it would also cost more time for Mark to get it into the Git 
> > documentation
> > instead of into the LilyPond documentation.
> > [...etc]
>
>
> Many thanks, Carl.  I had exactly the same learning
> experience as you and hold exactly the the same
> view as you on this and the other points you make.
> We can consider moving documentation into the git
> arena at a later stage if it seems to be generally
> useful.  But let's see it written first.
>
> Thanks for explaining this so clearly.
>
> My take on the learning experience is below ...
>
> > On 12/27/09 6:45 PM, "John Mandereau" <address@hidden> wrote:
> >
> > > Le dimanche 27 décembre 2009 à 18:20 -0700, Carl Sorensen a écrit :
> > > > And I don't see much of a maintenance headache; basic git isn't 
> > > > likely to
> > > > change much, and all we're using is basic git.
>
> > I can remember spending days trying to figure out how to work with 
> > Git.  I
> > read tutorial after tutorial, and man page after man page, and nothing
> > seemed to make sense.  Then, gradually, it started to make sense to 
> > me, and
> > now I'm quite comfortable with the set of commands I regularly use.  But
> > unfortunately, I can't remember now exactly what was so hard about it.
>
> In my case the main stumbling block was the jargon.
> What was a "commit", a "committish"; what did "checkout"
> mean and what exactly did it do?  There was also "index",
> "working tree", "head", "pushing/pulling", "rebasing", and
> many more.  The "explanation" of one of these concepts was
> in terms of the other still-not-understood concepts.  And
> the man pages were virtually useless initially - they just
> gave a list of still-meaningless options.
>
> I think it was the necessity to grasp all these concepts
> at the same time that made starting with git so hard.
>
> Trevor

A one of the newer of noobs, I can testify that the biggest problems I'm 
having with git are not seeing how git becomes aware of changes I might 
make: do I edit from within { git gui/gitk/lilycontrib } or use an 
external editor, and more importantly, *what* do I edit: where are the 
bits and pieces which eventually become lilypond, what parts of the 
source should I look at and where/how do I find them? After asking what 
turned out to be a damfool question of a fellow doc helper ( his reply 
made it clear to me that I was barking up the wrong source tree!), I 
moved on to the next chapter in the CG, finding to my wonder and 
surprise, that all I needed from git was git pull -r and nothing more, 
at least at my elementary level of contribtion. I'd been beating my head 
against trying to grok the build mechanism in its entirety, and while 
making some progress, not having a great deal of fun. I've since 
discovered that all Graham needs from me at the moment is easy to do 
entirely without reference to sources, and therefore I'm fine as long as 
I keep my local repo refreshed and the docs rebuilt.

Proposals for the CG which set up two stages or tracks, one for the 
basic text and small sippet editors, the other for internalists and hard 
core coders, would git my vote.

Colin
--
A good juggler can always find work.
 - attributed to L. Pacioli (1445 - 1517)