Re: [PATCH] translations: Make GIT Committish: lines obsolete
Hi, On Sat, 13 Jan 2007, Jan Nieuwenhuizen wrote: Johannes Schindelin [EMAIL PROTECTED] writes: Use git to determine when the translation last changed instead of relying on the GIT Committish line. Thanks for helping to solve this silly Git issue. However, I do not understand, how can Git know what original version was translated? Well, it can't. As I mentioned in my email, the committer has to make sure that he is committing an up-to-date translation, i.e. that it corresponds to the English documentation in the _same_ revision. It is perfectly possible that the translater copies the entire site (currently identifying and freezing the original copy by adding Git Committish: in those files), translates all files, and commits 2 weeks later. In the mean time, the original site has seen several updates. Using this patch, will the correct diff be shown to the translator to help her incorporating the changes made in the mean time? It _can_ be done, but is a little more involved. The basic idea is to introduce a side branch starting at the revision this translation is based on. Then, just commit the translation (which means that the translated text corresponds exactly to the English text in that revision). Merge the result back into the main branch. In git commands: # replace myweb~20 by whatever revision this is based on $ git checkout -b sidebranch myweb~20 # apply the patch (assuming you got it as a mail with an inlined patch) $ git am themailboxfilewiththepatch # go back to main branch $ git checkout myweb # merge the sidebranch $ git pull . sidebranch (# with git 1.5.0 this will be instead $ git merge sidebranch) The commit ancestry now looks like this: myweb~21 - myweb~20 - ... - myweb \/ sidebranch Note that what was myweb~20 before is now myweb~21, becasuse we added a commit to that branch. This will _only_ work, however, if myweb~20 .. myweb~1 do _not_ touch files of that particular translation (otherwise _they_ would be found, instead of the changes in sidebranch). Having said that, I doubt that it will happen all that often: Once we have reasonably up-to-date translations, the updates will be small, and probably applied very fast. And for new translations, the contributors can use make check-translation themselves, to find the spots they have to update before submission. Ciao, Dscho ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] translations: Make GIT Committish: lines obsolete
Hi, On Sat, 13 Jan 2007, John Mandereau wrote: If a translator polishes translation of a page and commit without running check-translation first, he will miss changes in English pages. If the translator does not commit halfway through _and_ pull _and_ continues polishing _and_ commits without checking translation first, it still works. My patch works like this: for every file to check, find the most recent commit which changed that file. Compare the version of the corresponding _English_ file in the working tree with the version in that commit. So something like 1. translate 2. hack hack hack 3. polish translation 4. pull upstream 5. check still works as expected. I'd prefer a script that update the committishes in translated pages automatically when a translator has made sure the translation is synced with the last fetched remote head. That is reasonably easy, too, but will add one commit. Of course, the commit then says I checked the translation at this stage and am confident it is up-to-date, which might be a desired thing. It is perfectly possible that the translater copies the entire site (currently identifying and freezing the original copy by adding Git Committish: in those files), translates all files, and commits 2 weeks later. In the mean time, the original site has seen several updates. Agreed. This is even very probable, as Git newbies may pull several times before they understand they should add and commit newly translated files. Yes, this is a problem. Using this patch, will the correct diff be shown to the translator to help her incorporating the changes made in the mean time? After a quick test, I say yes, but only if you do things right from the beginning with Git, which is seldom true. Current check-translation system is slightly more tolerant and reliable IMHO. As I said, it was a fun exercise. Ciao, Dscho ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] translations: Make GIT Committish: lines obsolete
Hi, On Sat, 13 Jan 2007, Till Rettig wrote: I just did the check-translation and it showed fatal error about some git comment numbers. What error did it show? And what commit (or _did_ you mean comment?) numbers were they? If in doubt, you can always create a throwaway branch from that revision: Say git log to find which commit you changed the numbers (say git log -p to see the diffs interspersed), and then say $ git checkout -b temp commit Ciao, Dscho ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] translations: Make GIT Committish: lines obsolete
Hi, On Sat, 13 Jan 2007, John Mandereau wrote: See also Jean-Charles's gitrux, that he recently sent on this list. I missed that. I also cannot find it in the archives. What does it do? Ciao, Dscho ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Updated spanish translation
Le lundi 08 janvier 2007 à 04:03 -0600, Daniel Tonda Castillo a écrit : Second: There's a typo in site/about/automated-engraving/input-format.html . Where it says: The above is another expression, and therefore, it many combined again with a simultaneous expression (in this case, a half note). Probably should read: The above is another expression, and therefore, it may be combined again with a simultaneous expression (in this case, a half note). Thanks, fixed. Greetings -- John Mandereau [EMAIL PROTECTED] ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: German update in three patches
Hi, On Sat, 13 Jan 2007, Till Rettig wrote: I always get patch files from older patches that are definitely not actual anymore -- can I somehow remove them myself? You see it by the number of the current files: there are obviously six (older) changes in my git that are not applied to the master git. But it doesn't make sense to apply them anymore because they are outdated. There are several ways to handle that. In my order of preference, the two (IMHO) best ways: - if you _know_ that the patches will apply cleanly against the upstream, and you _know_ you want to submit three patches, say $ git format-patch HEAD~3 - if you don't know if the patches apply cleanly, you can start a new branch, cherry-picking your way through the commits you want to save. For example, if you want to save the commits myweb~4, myweb~2 and myweb, do this: # start a new branch, called startanew, branching from web/master $ git checkout -b startanew web/master # pick the three commits $ git cherry-pick myweb~4 $ git cherry-pick myweb~2 $ git cherry-pick myweb To throw away _all_ your previous work in myweb, and _only_ retain these three commits, do # go back to the branch myweb $ git checkout myweb # replace the _complete_ history of the current branch by that of startanew $ git reset --hard startanew # delete the branch startanew $ git branch -d startanew If you want to retain just the last n commits, you might want to play with git-rebase (better read the documentation for that, since I am uncomfortable with that command). Hth, Dscho ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: German update in three patches
John Mandereau wrote: What command exactly do you use to generate patches? The following should make clean patches, as long as you committed all your changes and pulled: git-format-patch web/master..myweb Yes, I used this without the ..myweb part. I see there is some differences: some recommend to use git-format-patch HEAD^ and the others git-format-patch web/master (or then with this ..myweb continuation) Anyway, the most important is that your patches cleanly apply on the latest git.sv.gnu.org. These patches you sent are not clean: I had to fix a committish manually, and you made documentation.html translation in site/ !!! When I am in a bad mood, I may ask you to resend clean patches ;-) Yes, that's what you should do. I'm really sorry about this documentation issue! Thanks for changing it. But I still don't know how to keep the diffs clean. I found that there is a difference: git-rev-parse HEAD^ gives another commitish than git-rev-parse web/master. I used the latter one because that's what I found in the README. I guess one is my local one and the other the one from the internet. Well, now it asked me some merge, and I changed the parts in the and made git add and git-commit. Now it doesn't complain anymore about these differences: is this how you do a merge, then? According to 'make LANG=de check-translation', the German pages are up to date; I hope you make sure it is correct. Yes, now the script gives me the output that the site/documentation is changed. But this is the mistake that I made, so it is actually about de/translation or in other words: you redid the change I did to site/documentation. Should I just commit the documentation file again with the new commitish number? Will that stop the check-translation script from telling me about a page? I will have to make some other changes to the translation: I will try it another time with the commands from the README, but you should complain if it is not cleanly applying, then I might just start a total new branch and continue with this one. Greetings Till ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: German update in three patches
Hi, On Sun, 14 Jan 2007, Till Rettig wrote: John Mandereau wrote: What command exactly do you use to generate patches? The following should make clean patches, as long as you committed all your changes and pulled: git-format-patch web/master..myweb Yes, I used this without the ..myweb part. I see there is some differences: some recommend to use git-format-patch HEAD^ and the others git-format-patch web/master (or then with this ..myweb continuation) Basically, if you omit the ..commit part, it assumes ..HEAD. I found that there is a difference: git-rev-parse HEAD^ gives another commitish than git-rev-parse web/master. This is expected. HEAD^ is the parent of your current (private) branch, whereas web/master is the upstream (public) one. So they never match (except after exactly one commit after branching from web/master). Well, now it asked me some merge, and I changed the parts in the and made git add and git-commit. Now it doesn't complain anymore about these differences: is this how you do a merge, then? Yes. Usually you expect no conflicts (this is what you see between , and ). But in your case, some changes which you did not submit (or which were not applied) touched the same parts, so they conflicted. BTW If you _know_ that something _will_ conflict, you can undo commits with git revert commit. I say undo, because this will revert the patch, but _add_ a commit. The upside is, you can also revert older commits, e.g. HEAD~5. Ciao, Dscho ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Syntax to unset avoid-slur by default
Maximilian Albert escreveu: Hi, in answer to Graham's request a couple of days ago I agreed to add the avoid-slur settings to scm/script.scm. When it came to Gregorian chant, I thought it might be best to leave the value unset by default for those scripts (since slurs don't make sense in chant anyway, do they?). My moderate knowledge of scheme seems to imply that (avoid-slur . nil) the right way to do that. Is this correct? No, just leave it out. Or use (avoid-slur . #f) nil is LISP. Lily uses Scheme. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen LilyPond Software Design -- Code for Music Notation http://www.lilypond-design.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Updated spanish translation
Greetings: After the update what do you recommend that the spanish translation team tackle? Daniel Tonda C. John Mandereau escribió: Le lundi 08 janvier 2007 à 04:03 -0600, Daniel Tonda Castillo a écrit : Second: There's a typo in site/about/automated-engraving/input-format.html . Where it says: The above is another expression, and therefore, it many combined again with a simultaneous expression (in this case, a half note). Probably should read: The above is another expression, and therefore, it may be combined again with a simultaneous expression (in this case, a half note). Thanks, fixed. Greetings -- Anyone who has had a bull by the tail knows five or six more things than someone who hasn't. -- Mark Twain begin:vcard fn:Daniel Tonda Castillo n:Tonda Castillo;Daniel email;internet:[EMAIL PROTECTED] version:2.1 end:vcard ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
