Op zaterdag 06-06-2009 om 05:08 uur [tijdzone -0700], schreef Graham Percival:
> That would have been very useful to know six months ago, when I > wrote the first draft of the CG and asked everybody to check it. ..didn't know about this then, I'm not much of a git guru. > What should we do for pushing? Is > git push origin > ok, or should it be > git push > ? (I just checked, and "git push" works... but is that the _best_ > option?) origin should not be necessary. > The initial setup isn't really a problem but it is. You said it yourself: John and I have told each other "I don't have newweb/ right now". If lilypond-web were a single repo, and git came initialized in a sane way, ie, with the gnu: alias, then git clone --depth=1 gnu:lilypond-web is less than 10sec away? It is the facts that cloning it takes very long and/or has a mantra that you cannot remember, that make it easier to ask someone else than getting it. I think. > We recommend (and I follow) putting lilypond, web, and > lilypond/translations in separate directories. Of course. Another reason for web to be in a separate repo (or to make it a simple directory Documentation/web). > Basically, the entire CG-git stuff is modeled around the idea that > we want contributors working on lilypond stuff (docs, > translations, bugfixes), *not* working on understanding git stuff. Yes, but that's one of the reasons that the choice for [the speed of] git still comes with a price. > Unless we specifically say "ok, X, you're now in charge of fixing > typos on the website", X is very likely to say "nah, I'm not going > to bother fixing this typo report; I'll let somebody else handle > it". > > I know this very well, since I've been X at least half the time. > :) Yes, that's unfortunate. Both the general observation and the equation graham==X. I suppose we should work on changing both :-) > The actual experiments would be done on a separate branch -- but > only the initial experiments. Basically, I want to: > - merge web/ and master/ > - copy the new master/ into gop/ Do I understand these steps to be something like [the just tested over here] git checkout -b web-gop origin/web mkdir -p Documentation/web mv .gitignore * Documentation/web/ git add . # watch out for any crufty in . moved to web/ :-) git add -u . git commit -m 'Prepare web for merge, move into Documentation/web.' git checkout -b gop origin/master git merge web-gop ? There's one thing that still bothers me about this, we'd need to declare Documentation/web 'dead' for branches other than master, eg, stable/2.12, whereas the rest of Documentation/ would not be dead in stable/2.12. Would this be a problem? > - work on gop/ for 3-4 weeks > - merge gop/ to master, then delete gop/ > > In the long term, we would only have a single master/ branch, plus > the various temporary/private development branches. Okay. > (yes, something would happen to gub-samco and lilypad-macos). *poof* gub-samco is gone :-) Han-Wen needs to move lilypad-macos. > I'm also not saying that a certain amount of upfront difficulty is > a *bad* thing. Somebody could make the argument that if a > potential contributor isn't willing to learn texinfo + git + > making functional diffs + our policies, then they don't have the > dedication to be a good contributor anyway. > > I'm *not* making this argument myself. Rather, I'd say that if > somebody can't figure out the CG -- as long as we make the > repositories, branches, and CG as easy to follow as possible -- > then they probably would not be a net contributor. But if I'm > going to feel good about rejecting (apparently) sincere offers of > help, then I want to be maoing certain that the CG (and git repos, > branches, etc) **are** as easy to follow as possible. Yes, quite agree. Greetings, Jan. -- Jan Nieuwenhuizen <jann...@gnu.org> | GNU LilyPond - The music typesetter AvatarĀ®: http://AvatarAcademy.nl | http://lilypond.org _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel