Contributor Guide "volunteers" needed
It's just past 9pm local time on Sunday. I went to university, took some pictures, got sucked into work and being polite to my supervisor, had dinner and bought breakfast for the next few days, and had a shower. Let's face it: I'm never going to finish the CG at this rate. So we need some "volunteers" to finish the task. HIGH PRIORITY: - can somebody maoing check the maoing git commands in CG 1 already? Either somebody with a big internet connection, or somebody who knows git so intimiately that he can state with absolute certainty that the commands work. Desired: cut&paste methods for git work. Don't explain about branches. Ideally don't ask people to edit files. Don't explain why git is fantastic and can create a nice cup of proper British tea, which incidentally I would be willing to commit a minor felony to get right now, or why git is so much better than cvs. Design these docs for idiots who don't want to think. Not because we want braindead idiots contributing to lilypond, but because we want people contributing to lilypnod to spend all their brainpower working on their contributions, not puzzling out the git docs, which incidentally suck worse than the instant cappacino packets (milk and sugar included in the powder!) I bought last week. I think the current format is fine, as long as the @example sections actually work. I don't know if they do or not. One Frog commented that the "git-format patch HEAD" didn't work and he had to spend half an hour figuring out the right command, which is a perfect example of what we want to avoid. MEDIUM PRIORITY: CG 1 git - Trevor, you are volunteered to perfect CG 1.5 - Jonathan, you are volunteered to perfect the rest of CG 1. If you want to check the @example commands yourself, great. If not, keep on pestering other people to do this. - both of you work together to make all of the CG work well. I have to admit that I was surprised to see the command-line stuff in CG 1.5; maybe we should just start the CG with "getting git" (easy in linux, moderately easy in OSX, dunno how in windows) and then have a unified rest of the CG for everybody. CG 3 docs - Jonathan, you are volunteered to test this section and identify major weaknesses. Here's one: I haven't mentioned that the manuals are in Documentation/user/, the CG is in Documetnation/devel/, snippets are input/lsr and input/new (and doc people should read CG 4), IR comes from scm/, etc. - any doc team members should add to the policies whenever they find something missing. CG 7 programming - Carl, this is your domain. Add whatever the Frogs need to know. CG 7.4 will require input from Werner, but only once we've caught up on other stuff. LOW PRIORITY - CG 2. to be done in 2.13. - CG 4. to be done whenever we do website stuff, we I'm going to optimistically claim to look at after the chinese new year (it's a *huge* thing here in Singapore). Not so much because of the holiday, but because that's when I think we'll have a demo and can start rehearsals, and I'll have a much stronger case if I tell my supervisor that everything's fine. - CG 5. Valentin, you're volunteered to write this after your opera is over and you've caught up on other stuff, like the Report. - CG 6. I'll tackle this sometime. - CG 8. I'll tackle this sometime. If the high and medium-priority stuff is done by the end of Jan, that'll be great. I'll do another GOP advert at the beginning of Feb. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: rsync for docs?
On Thu, Jan 15, 2009 at 04:15:57PM +0100, Jan Nieuwenhuizen wrote: > Op donderdag 15-01-2009 om 22:17 uur [tijdzone +0800], schreef Graham > Percival: > > Hi Graham, > > > Why did you add an rsync dependency for the docs? For uploading > > the docs, I'd understand, but for simply building them...? > > make web-install (and also make test) uses rsync. I found out > trying to build the package for openSUSE. Don't people just do "make web"? I know that's what I do... ... hmm, after a quick check of the docs, I guess they're fine as they are. When the Install chapter moves into the CG, we'll make a separate section for "easy doc compiling" (using GUB, texi2html, and whatever other programs are absolutely necessary) -- we're getting more and more windows users wanting to contribute. Linux users probably have rsync installed already (or else it's trivial to add), but windows requires a lot more fiddling to get basic software installed, and we don't want to scare off potential contributors (like Trevor!) with items that aren't strictly requirements. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond-book: \lilypond vs. lilypond environment
On Fri, Jan 16, 2009 at 07:14:34PM +0100, Werner LEMBERG wrote: > > a long time ago, if I remember correctly, there was a difference > between lilypond-book's handling of \lilypond and a `lilypond' > environment: The former was (mainly) for inline use, the latter > (mainly) for use in a paragraph of its own. How was \lilypondfile handled? IMO, \lilypondfile and \lilypond should have the same behavior, but it doesn't make sense for \lilypondfile to be for inline use. What about somethine like \inlinelilypond instead? This would also avoid the compatibility problem. Other than this nitpick, I love the suggestion -- I've occasionally wanted to include notation inline, but since it never worked I always ended up rewording my paragraphs so it wasn't necessary. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
LilyPond for Vista
Hi guys, My operating system is Windows Vista. I noticed there isn't a LilyPond version for Vista yet. Is that true? Or will the Windows XP version work on Vista? Thanks, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LilyPond for Vista
2009/1/18 John : > My operating system is Windows Vista. I noticed there isn't a LilyPond version > for Vista yet. > Is that true? Or will the Windows XP version work on Vista? Yes it will. (If it's 64-bits Vista, it will run as 32 bits). Cheers, Valentin ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Contributor Guide "volunteers" needed
2009/1/18 Graham Percival : > HIGH PRIORITY: > - can somebody maoing check the maoing git commands in CG 1 > already? Either somebody with a big internet connection, or > somebody who knows git so intimiately that he can state with > absolute certainty that the commands work. Done. All of them work fine (but se the comment on 1.3.1 below). Note that I only performed the commands marked with a FIXME (in sections 1.1.2 - 1.1.4) and had a look at the other ones which didn't involve a lot of sophisticated stuff (I didn't bother with GUB, for example). I didn't do any further testing, nor did I figure out what the correct commands in section 1.1.4 should be. Also, I couldn't review section 1.5 as I'm on Linux exclusively. Two comments regarding the CG in general: 1) The link on the intro page of the CG, i.e., at http://www.kainhofer.com/~lilypond/Documentation/devel/contrib-guide/index.html which points to the "one big page" version is broken, and so is the link to the PDF version (although both links work fine from one level higher, i.e., from http://www.kainhofer.com/~lilypond/Documentation/devel/index.html ). 2) I very much like well-structured documents. However, I find it slightly annoying to have to descend _three_ levels before getting to the first piece of text. Two levels would be acceptable IMHO, but personally I'd prefer if section 1.1 (say) could be displayed on a single page comprising subsections 1.1.1 - 1.1.7 (still including the table of contents, of course, so that they can be quickly navigated to). I find it difficult to have to go back after reading just a single short paragraph (or even sentence). And here are a few questions/comments on specific sections: 1.2.2: One precautionary question: Do unexpected things happen if the user is working on a branch other than master (and has local changes)? Should git pull origin only be performed on the master branch? I'm not familiar enough with git internals to judge this. 1.2.3: I'd add something along the lines of "In files where conflicts occurred, the critical parts are marked with <<< ... === ... >>>." Of course, there is a lot more to say, but this might already help. 1.2.4: I know that you (Graham) said that you won't bother with that section, but anyway: Paragraph No. 5 refers to a "git fetch command above" which was never mentioned before. The same presumably applies to the "git checkout command above" in the next paragraph (which I guess doesn't refer to the commands in sections 1.1.2 - 1.1.4 where "git checkout" was used, too). Moreover, the last paragraph refers to "this README" when there is no README document there. 1.3.1: AFAICT the second command "git-format-patch HEAD" doesn't do anything because HEAD is the latest commit the user did, i.e., it already includes his changes. Thus there is no diff which could be produced. I suppose it should be changed to "git-format-patch master" instead (or whatever branch he is working on). Am I missing something? git gurus please correct me. Cheers, Max ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Contributor Guide "volunteers" needed
On Sun, Jan 18, 2009 at 03:47:34PM +0100, Maximilian Albert wrote: > 2009/1/18 Graham Percival : > > > - can somebody maoing check the maoing git commands in CG 1 > > already? Either somebody with a big internet connection, or > > Done. All of them work fine (but se the comment on 1.3.1 below). By "work fine", I also want to know that: - future pulls work with simply "git pull" or "git pull origin" (whatever is listed in that section) - creating patches works with whatever the command is (whether that's "git-format-patch HEAD or MASTER or whatever) - "git push" or "git push origin" or whatever works for users with commit ability. This isn't directed at you (I don't think you can test point #3), but I include them here so that other people don't think this job is finished. :) > nor did I figure out what the correct > commands in section 1.1.4 should be. I include this here for emphasis. > Two comments regarding the CG in general: > > 2) I very much like well-structured documents. However, I find it > slightly annoying to have to descend _three_ levels before getting to > the first piece of text. Two levels would be acceptable IMHO, but > personally I'd prefer if section 1.1 (say) could be displayed on a > single page comprising subsections 1.1.1 - 1.1.7 (still including the > table of contents, of course, so that they can be quickly navigated > to). I find it difficult to have to go back after reading just a > single short paragraph (or even sentence). The original makefile used --split=section; I suggest that this be used again. When the CG got merged into master, AFAIK it started to use the same doc build system as we use for the LM and NR. > 1.2.4: I know that you (Graham) said that you won't bother with that > section, but anyway: Paragraph No. 5 refers to a "git fetch command > above" which was never mentioned before. The same presumably applies > to the "git checkout command above" in the next paragraph (which I > guess doesn't refer to the commands in sections 1.1.2 - 1.1.4 where > "git checkout" was used, too). Moreover, the last paragraph refers to > "this README" when there is no README document there. Yeah, I copied it directly from one of the IIRC 5 different README files we have floating around. As I said, I wasn't going to bother editing that section. :) Fortunately, Trevor and Jonathan have "volunteered" to handle CG 1, so this is their responsibility now. :):) Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Contributor Guide "volunteers" needed
On 1/18/09 6:25 AM, "Graham Percival" wrote: > > CG 7 programming > - Carl, this is your domain. Add whatever the Frogs need to know. > CG 7.4 will require input from Werner, but only once we've > caught up on other stuff. > OK, I'll continue with my work on CG 7. Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Contributor Guide "volunteers" needed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Sonntag, 18. Januar 2009 15:47:34 schrieb Maximilian Albert: > 1.3.1: AFAICT the second command "git-format-patch HEAD" doesn't do > anything because HEAD is the latest commit the user did, i.e., it > already includes his changes. Thus there is no diff which could be > produced. I suppose it should be changed to "git-format-patch master" > instead (or whatever branch he is working on). This won't work either, because master==HEAD ;-) I suppose it should rather be git-format-patch origin for one patch for each local commit or git-format-patch HEAD^1 for just the last local commit. Cheers, Reinhold - -- - -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFJc0hBTqjEwhXvPN0RAttXAJ9zxj1Ezh6krAdW+nLMs02Je0xcMgCg1VUP GRKBTjnkp6BWL+SpSR4xeSo= =WSLl -END PGP SIGNATURE- ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Contributor Guide "volunteers" needed
2009/1/18 Graham Percival : > On Sun, Jan 18, 2009 at 03:47:34PM +0100, Maximilian Albert wrote: >> 2009/1/18 Graham Percival : >> >> > - can somebody maoing check the maoing git commands in CG 1 >> > already? Either somebody with a big internet connection, or >> >> Done. All of them work fine (but se the comment on 1.3.1 below). > > By "work fine", I also want to know that: > - future pulls work with simply "git pull" or "git pull origin" > (whatever is listed in that section) > - creating patches works with whatever the command is > (whether that's "git-format-patch HEAD or MASTER or whatever) Should this take the possibility into account that people are able to create their own branches? Or would it be OK to assume they work on master (because if they know how to create branches they also know how to use these commands)? Anyway, when I "reset --hard" the master branch to a previous commit (so that it differs from remotes/origin/master and I don't have to wait for any of the developers to commit something to the remote branch) then both "git pull" and "git pull origin" work fine to synchronize master and remotes/origin/master again. This only applies if there are no local changes, though. In case there are, then issuing either command produces a merge commit so that the commit graph now looks like this: * master after merging |\ | \ | \ * * remotes/origin/master (on the right) \ | \| * | I'm not sure if this constellation can cause problems when producing patches. It seems that the command "git-format-patch origin" works fine, though (Rainer, thanks for pointing out that this should be the correct command). I personally prefer to checkout the remote branch before pulling and then doing a rebase: git-checkout remotes/origin/master git-pull git-rebase remotes/origin/master master This produces a linear history, which I personally find "cleaner". :-) But I suppose that "git-format-patch origin" does the right thing in both situations. I don't know what you prefer to be included in the CG. > - "git push" or "git push origin" or whatever works for users with > commit ability. > > This isn't directed at you (I don't think you can test point #3), Correct. Max ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Contributor Guide "volunteers" needed
2009/1/18 Reinhold Kainhofer : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Am Sonntag, 18. Januar 2009 15:47:34 schrieb Maximilian Albert: >> 1.3.1: AFAICT the second command "git-format-patch HEAD" doesn't do >> anything because HEAD is the latest commit the user did, i.e., it >> already includes his changes. Thus there is no diff which could be >> produced. I suppose it should be changed to "git-format-patch master" >> instead (or whatever branch he is working on). > > This won't work either, because master==HEAD ;-) Whoops, you are of course right. I normally work on a separate branch and keep master synchronized with remotes/origin/master, that's why it usually works for me. :-) > I suppose it should rather be > git-format-patch origin > for one patch for each local commit or > git-format-patch HEAD^1 > for just the last local commit. Correct. Or else "git-format-patch -n" for the last n local commits (i.e., "git-format-patch -1" for only the last local commit). Max ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Contributor Guide "volunteers" needed
Graham, you wrote Sunday, January 18, 2009 1:25 PM MEDIUM PRIORITY: CG 1 git - Trevor, you are volunteered to perfect CG 1.5 I did this last week, unless someone points out what is wrong with it. - Jonathan, you are volunteered to perfect the rest of CG 1. If you want to check the @example commands yourself, great. If not, keep on pestering other people to do this. - both of you work together to make all of the CG work well. I have to admit that I was surprised to see the command-line stuff in CG 1.5; maybe we should just start the CG with "getting git" (easy in linux, moderately easy in OSX, dunno how in windows) Installing git in Windows is in 1.5.2. It is trivial - it comes with a Windows install wrapper. The only command line stuff is in 1.5.3 - to initialise git. Everything else in done in in the git gui and gitk panels, which incidently are the same on all platforms, AFAIK, so no one need use the command line for any of the usual tasks. I only use the command line for pushing to origin/master. and then have a unified rest of the CG for everybody. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LilyPond for Vista
2009/1/18 Valentin Villenave : > 2009/1/18 John : > >> My operating system is Windows Vista. I noticed there isn't a LilyPond >> version >> for Vista yet. >> Is that true? Or will the Windows XP version work on Vista? > > Yes it will. (If it's 64-bits Vista, it will run as 32 bits). I think we should label the version as also being for Vista. I could prepare a patch. -- Francisco Vila. Badajoz (Spain) http://www.paconet.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Contributor Guide "volunteers" needed
Graham Percival wrote: HIGH PRIORITY: - can somebody maoing check the maoing git commands in CG 1 already? Either somebody with a big internet connection, or somebody who knows git so intimiately that he can state with absolute certainty that the commands work. Running Ubuntu 8.04 Checking these now. 1. Problem in 1.1.3: http://kainhofer.com/~lilypond/Documentation/devel/contrib-guide/Website-source-code.html#Website-source-code The first command here creates a dir "lilypod-web" instead of "lilypond-web" 2. 1.1.6: this command in section 1.1.6 didn't do anything when I ran it: git://git.sv.gnu.org/lilypond.git Here's the terminal output: j...@bashtop:~$ git://git.sv.gnu.org/lilypond.git bash: git://git.sv.gnu.org/lilypond.git: No such file or directory I tried it in a browser also but it didn't do anything there, either. Is this even a terminal command? 3. 1.1.6: Third item on the same page didn't do anything for me: ssh://git.sv.gnu.org/srv/git/lilypond.git I tried running it again as "ssh git.sv.gnu.org/srv/git/lilypond.git" without results. The http link worked fine. 4. 1.4.1: The "gitk" command has a dependency--need to apt-get it to run the command. Not a big deal but I thought I'd mention it. NOT CHECKED: I didn't try the commands for creating patches and applying them yet since I don't have any patches to make at the moment. The patches I sent to Carl already were done with the diff -u command instead of git. Desired: cut&paste methods for git work. Don't explain about branches. Ideally don't ask people to edit files. Don't explain An admirable goal! I agree. why git is fantastic and can create a nice cup of proper British tea, which incidentally I would be willing to commit a minor felony to get right now, or why git is so much better than cvs. Design these docs for idiots who don't want to think. Not because we want braindead idiots contributing to lilypond, but because we want people contributing to lilypnod to spend all their brainpower working on their contributions, not puzzling out the git docs, which incidentally suck worse than the instant cappacino packets (milk and sugar included in the powder!) I bought last week. I think the current format is fine, as long as the @example sections actually work. I don't know if they do or not. One Frog commented that the "git-format patch HEAD" didn't work and he had to spend half an hour figuring out the right command, which is a perfect example of what we want to avoid. Apart from the problems above I think they're fine. I do appreciate having all those commands organized and explained like that. Thanks. :) Jon -- Jonathan Kulp http://www.jonathankulp.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Contributor Guide "volunteers" needed
On Sun, Jan 18, 2009 at 04:18:24PM +0100, Reinhold Kainhofer wrote: > I suppose it should rather be >git-format-patch origin > for one patch for each local commit or >git-format-patch HEAD^1 > for just the last local commit. Let's go with git-format-patch origin We don't want new contributors losing their patches. I'd rather have Carl need to filter out a few extra patches rather than have a disappointing start for new contributors. If problems persist with multiple patches, Carl can say a few words after things have settled down. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Contributor Guide "volunteers" needed
On Sun, Jan 18, 2009 at 04:27:00PM +0100, Maximilian Albert wrote: > 2009/1/18 Graham Percival : > > By "work fine", I also want to know that: > > - future pulls work with simply "git pull" or "git pull origin" > > (whatever is listed in that section) > > - creating patches works with whatever the command is > > (whether that's "git-format-patch HEAD or MASTER or whatever) > > Should this take the possibility into account that people are able to > create their own branches? No. > Or would it be OK to assume they work on > master (because if they know how to create branches they also know how > to use these commands)? Yes. The target audience is this: "Hi guys, I have OSX and I noticed a few typos in the docs. I'd like to fix them, but there's a lot of mistakes so I don't want to type them all in an email. I've never used git before, but I have macports set up and have run port install git." Then we say "read CG 1 to get started with git, and CG 2 to find otu what file(s) to edit to fix the typos". $helpful_user then looks at CG 1, does a copy&paste to get the source, edits the files, does more copy&paste to update git, commit the files, and produce a patch. > Anyway, when I "reset --hard" the master branch to a previous commit > (so that it differs from remotes/origin/master and I don't have to > wait for any of the developers to commit something to the remote > branch) then both "git pull" and "git pull origin" work fine to > synchronize master and remotes/origin/master again. I've had problems with just "git pull"... > This only applies if there are no local changes, though. ... ah, for precisely for this reason. :) > In case there are, then issuing > either command produces a merge commit so that the commit graph now > looks like this: > > * master after merging > |\ > | \ > | \ > * * remotes/origin/master (on the right) >\ | > \| > * > | > > I'm not sure if this constellation can cause problems when producing > patches. It seems that the command "git-format-patch origin" works > fine, though (Rainer, thanks for pointing out that this should be the > correct command). See, I've been using git for a few years now, and I only barely understand what you're talking about. (not because I'm an idiot; just because I've never been willing to put any time or effort towards learning any git theory. If I can use it like cvs -- checkout, add, commit, update -- then I'm happy) > I personally prefer to checkout the remote branch before pulling and > then doing a rebase: > >git-checkout remotes/origin/master >git-pull >git-rebase remotes/origin/master master > > This produces a linear history, which I personally find "cleaner". :-) > But I suppose that "git-format-patch origin" does the right thing in > both situations. I don't know what you prefer to be included in the > CG. Mao. I'm totally lost now. Git people, please discuss and modify the CG accordingly. I promise to read the non-theory parts of the CG in a week or two, and will use whatever commands are there. In the copy&paste sections. I still plan on ignoring any paragraph which has more than three sentences, or any section which contains more than three paragraphs. :) Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Contributor Guide "volunteers" needed
On Sun, Jan 18, 2009 at 03:39:16PM -, Trevor Daniels wrote: > > Graham, you wrote Sunday, January 18, 2009 1:25 PM > >> MEDIUM PRIORITY: >> CG 1 git >> - Trevor, you are volunteered to perfect CG 1.5 > > I did this last week, unless someone points out what is > wrong with it. Well, "perfect documentation" is a never-ending task. All I want is for you to respond to any issues when they arise. :) > The only command line stuff is in 1.5.3 - to initialise git. > Everything else in done in in the git gui and gitk panels, which > incidently are the same on all platforms, AFAIK, so > no one need use the command line for any of the usual tasks. > I only use the command line for pushing to origin/master. Oh, sorry. I skimmed it quite quickly, and thought there was more command-line stuff than that. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Contributor Guide "volunteers" needed
On Sun, Jan 18, 2009 at 10:33:47AM -0600, Jonathan Kulp wrote: > http://kainhofer.com/~lilypond/Documentation/devel/contrib-guide/Website-source-code.html#Website-source-code > > The first command here creates a dir "lilypod-web" instead of "lilypond-web" Please fix -- you have git access, right? I can't remember if that got sorted out in the end. > 2. 1.1.6: this command in section 1.1.6 didn't do anything when I ran it: > > git://git.sv.gnu.org/lilypond.git > > I tried it in a browser also but it didn't do anything there, either. Is > this even a terminal command? It's a shortcut for advanced git people. Sorry, there should be some warning there about this only being for hardcore developers. IIRC the actual command-line would be git clone git://... but I'm not certain it's worth including that here, since git appears to have half a dozen different ways to get source code, and every git person has his own favorite command. > 3. 1.1.6: Third item on the same page didn't do anything for me: > > ssh://git.sv.gnu.org/srv/git/lilypond.git Same idea here -- they're workarounds for more advanced git people. There should be some kind of a warning about this. > 4. 1.4.1: The "gitk" command has a dependency--need to apt-get it to run > the command. Not a big deal but I thought I'd mention it. Hmm, IIRC in OSX it comes bundled with git. A warning about that would also be nice. :) > NOT CHECKED: I didn't try the commands for creating patches and applying > them yet since I don't have any patches to make at the moment. The > patches I sent to Carl already were done with the diff -u command > instead of git. Keep on doing that for another week or so, until the git people have settled on the best patch-making command for us. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Contributor Guide "volunteers" needed
2009/1/18 Graham Percival : > I've had problems with just "git pull"... > >> This only applies if there are no local changes, though. > > ... ah, for precisely for this reason. :) > >> In case there are, then issuing >> either command produces a merge commit so that the commit graph now >> looks like this: >> >> * master after merging >> |\ >> | \ >> | \ >> * * remotes/origin/master (on the right) >>\ | >> \| >> * >> | >> >> I'm not sure if this constellation can cause problems when producing >> patches. It seems that the command "git-format-patch origin" works >> fine, though (Rainer, thanks for pointing out that this should be the >> correct command). > > See, I've been using git for a few years now, and I only barely > understand what you're talking about. (not because I'm an idiot; > just because I've never been willing to put any time or effort > towards learning any git theory. If I can use it like cvs -- > checkout, add, commit, update -- then I'm happy) Honestly, I feel like anything else than a git expert. Anyway, probably my ASCII-arts above are not very clear. Perhaps this better illustrates what I mean. 1) Start with a repository where master and remotes/origin/master are identical (if they are not, you can say git-checkout -b test remotes/origin/master to create a branch called 'test'; in this case, replace 'master' with 'test' everywhere in the following steps). 2) git-reset --hard HEAD^ This discards the most recent commit on master so that master and remotes/origin/master now differ by precisely one commit. 3) Do a simple change in one of the files (e.g., add a line or something - doesn't really matter). 4) git-commit -a -m "Test commit on master" 5) git pull (or "git pull origin", I suppose they work identically) --> this creates the merge commit 6) Fire up gitk and look at the commit graph; it should look similar to what I tried to mimic in my ASCII arts. On the other hand, if you do the following instead: 1) - 4) as above 5) git-checkout remotes/origin/master 6) git pull 7) git-rebase remotes/origin/master master then you will see in gitk that master now sits nicely "on top of" remotes/origin/master. That's what I meant when I said "linear history". But as mentioned, I don't suppose there is any difference between the two methods as far as git-format-patch is concerned. However, I don't know whether git-format-patch gets confused when the user makes several commits with several pulls in between as in the first method above. Hmm, I just saw that that the second method gives a warning in step 5) saying that remotes/origin/master is not a local branch (well, obviously) and explaining how to create one if desired. I don't know if this will confuse newcomers. >>git-checkout remotes/origin/master >>git-pull >>git-rebase remotes/origin/master master >> >> This produces a linear history, which I personally find "cleaner". :-) >> But I suppose that "git-format-patch origin" does the right thing in >> both situations. I don't know what you prefer to be included in the >> CG. > > Mao. I'm totally lost now. See above. I hope it made things a bit clearer. Max ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Contributor Guide "volunteers" needed
Graham Percival wrote: On Sun, Jan 18, 2009 at 10:33:47AM -0600, Jonathan Kulp wrote: http://kainhofer.com/~lilypond/Documentation/devel/contrib-guide/Website-source-code.html#Website-source-code The first command here creates a dir "lilypod-web" instead of "lilypond-web" Please fix -- you have git access, right? I can't remember if that got sorted out in the end. 2. 1.1.6: this command in section 1.1.6 didn't do anything when I ran it: git://git.sv.gnu.org/lilypond.git I tried it in a browser also but it didn't do anything there, either. Is this even a terminal command? It's a shortcut for advanced git people. Sorry, there should be some warning there about this only being for hardcore developers. IIRC the actual command-line would be git clone git://... but I'm not certain it's worth including that here, since git appears to have half a dozen different ways to get source code, and every git person has his own favorite command. 3. 1.1.6: Third item on the same page didn't do anything for me: ssh://git.sv.gnu.org/srv/git/lilypond.git Same idea here -- they're workarounds for more advanced git people. There should be some kind of a warning about this. 4. 1.4.1: The "gitk" command has a dependency--need to apt-get it to run the command. Not a big deal but I thought I'd mention it. Hmm, IIRC in OSX it comes bundled with git. A warning about that would also be nice. :) Ok I've made a patch with these warnings and the typo correction. I don't have git access so I'll send the patch to Carl to apply. NOT CHECKED: I didn't try the commands for creating patches and applying them yet since I don't have any patches to make at the moment. The patches I sent to Carl already were done with the diff -u command instead of git. Keep on doing that for another week or so, until the git people have settled on the best patch-making command for us. Will do. Thanks, Jon -- Jonathan Kulp http://www.jonathankulp.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Contributor Guide "volunteers" needed
On Sun, Jan 18, 2009 at 09:25:13PM +0800, Graham Percival wrote: > It's just past 9pm local time on Sunday. I went to university, > took some pictures, got sucked into work and being polite to my > supervisor, had dinner and bought breakfast for the next few days, > and had a shower. Let's face it: I'm never going to finish the CG > at this rate. > > So we need some "volunteers" to finish the task. > > HIGH PRIORITY: > - can somebody maoing check the maoing git commands in CG 1 > already? Either somebody with a big internet connection, or > somebody who knows git so intimiately that he can state with > absolute certainty that the commands work. The most important thing about git commands that we should be *absolutely* consistent about is this: (1) git-format-patch origin ...versus... (2) git format-patch origin Out of the box, command (1) will only work for Git versions < 1.6.*, and command (2) will work for all Git versions. Since the latest Git is 1.6.*, and eventually everyone will be using it, we should get this right so we won't have to change the CG later to reflect this. -Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Contributor Guide "volunteers" needed
2009/1/18 Patrick McCarty : > The most important thing about git commands that we should be > *absolutely* consistent about is this: > > (1) git-format-patch origin > > ...versus... > > (2) git format-patch origin > > Out of the box, command (1) will only work for Git versions < 1.6.*, > and command (2) will work for all Git versions. Even in latest version, if you want to look at the git's man page, don't do man git format-patch but man git-format-patch which is a manpage request for a single-word command. The same is true for all other git commands. -- Francisco Vila. Badajoz (Spain) http://www.paconet.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Contributor Guide "volunteers" needed
On Sun, Jan 18, 2009 at 10:02:35PM +0100, Francisco Vila wrote: > 2009/1/18 Patrick McCarty : > > The most important thing about git commands that we should be > > *absolutely* consistent about is this: > > > > (1) git-format-patch origin > > > > ...versus... > > > > (2) git format-patch origin > > > > Out of the box, command (1) will only work for Git versions < 1.6.*, > > and command (2) will work for all Git versions. > > Even in latest version, if you want to look at the git's man page, don't do > > man git format-patch > > but > > man git-format-patch > > which is a manpage request for a single-word command. The same is true > for all other git commands. Yes, that's another inconsistency that is slightly annoying, but we should definitely explain that in the CG too. Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Please fix: japanese doc compilation
Hi,
someone added a japanese translation of the docs, but after enabling
it (so it is distributed), I get error (see below). Can someone fix
this, or disable the translation? This is a blocking issue for
releasing 2.12.2.
(/home/lilydev/vc/gub/target/linux-x86/build/lilypond-localhost--home-lilydev-v
c-lilypond-master/Documentation/user/./out-www/lilypond-learning.aux)
(./macros.pdftexi (./version.pdftexi))
Runaway argument?
{ja_\finish }\else \globaldefs = 1 \input txi-ja.tex \fi \closein 1 \endgroup \
ETC.
./lilypond-learning.pdftexi:58: Paragraph ended before \documentlanguagetrywith
outunderscore was complete.
\par
l.58
l.69: Unicode char \u8:音 not defined for Texinfo
l.69: Unicode char \u8:楽 not defined for Texinfo
l.69: Unicode char \u8:譜 not defined for Texinfo
l.69: Unicode char \u8:刻 not defined for Texinfo
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Please fix: japanese doc compilation
Hi Han-Wen, Han-Wen Nienhuys a écrit : someone added a japanese translation of the docs, but after enabling it (so it is distributed), I get error (see below). Can someone fix this, or disable the translation? This is a blocking issue for releasing 2.12.2. I suggest not to enable it or revert the commit, and I'll deal with this on Wednesday; I'm completely unavailable today and tomorrow. John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
