New Dutch PO file for 'lilypond' (version 2.19.26)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'lilypond' has been submitted by the Dutch team of translators. The file is available at: http://translationproject.org/latest/lilypond/nl.po (We can arrange things so that in the future such files are automatically e-mailed to you when they arrive. Ask at the address below if you want this.) All other PO files for your package are available in: http://translationproject.org/latest/lilypond/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: http://translationproject.org/domain/lilypond.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Git questions
Phil Holmes writes: > I'm updating master with LSR changes. I followed the CG, which says to run > a local LSR update, then one from the LSR itself. I think when I've done > this in the past, I created a commit from each run, then pushed both commits > in one go. This time I've pushed the local update to staging, then run the > LSR update against master. When I try to apply this update to > origin/staging, it fails, presumably because it's attempting to make the > same change twice. Possibly. > There's lots of ways I can get round this: the simplest is to let > master update from staging then re-run the LSR update. However, I was > wondering if I can avoid doing this. You can just run the LSR update on the state you pushed to staging. > One option would appear to be to checkout origin/staging and then > checkout the previous commit. This would effectively remove my first > commit, and I can apply my later patch. Does this have any bad > effects? Well, you can't push this to staging afterwards since it is no longer strictly ahead of staging: it sidestepped one commit. > Is there a better way? See above. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Git questions
I'm updating master with LSR changes. I followed the CG, which says to run a local LSR update, then one from the LSR itself. I think when I've done this in the past, I created a commit from each run, then pushed both commits in one go. This time I've pushed the local update to staging, then run the LSR update against master. When I try to apply this update to origin/staging, it fails, presumably because it's attempting to make the same change twice. There's lots of ways I can get round this: the simplest is to let master update from staging then re-run the LSR update. However, I was wondering if I can avoid doing this. One option would appear to be to checkout origin/staging and then checkout the previous commit. This would effectively remove my first commit, and I can apply my later patch. Does this have any bad effects? Is there a better way? TIA -- Phil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
