Re: Bad translation merge
David Kastrup d...@gnu.org writes: Hi, the recent translation merge apparently made some wrong choices when dealing with merge conflicts. Changes in staging have been overwritten in the following files: And that affects a lot more than just translations. I have removed that commit from origin/staging, and we'll have to investigate what happened. Francisco, do you remember the commands you used for merging translation into staging? I'll try repeating this on my own and see whether I can reproduce this. I can reproduce the problems when merging. It would appear that the history of the translation branch got messed up at some point of time in a manner that git can't recognize how to merge properly anymore. I will try to figure out what happened here. Please don't merge the translation branch to staging while I try figuring this out. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Bad translation merge
David Kastrup d...@gnu.org writes: David Kastrup d...@gnu.org writes: Hi, the recent translation merge apparently made some wrong choices when dealing with merge conflicts. Changes in staging have been overwritten in the following files: And that affects a lot more than just translations. I have removed that commit from origin/staging, and we'll have to investigate what happened. Francisco, do you remember the commands you used for merging translation into staging? I'll try repeating this on my own and see whether I can reproduce this. I can reproduce the problems when merging. It would appear that the history of the translation branch got messed up at some point of time in a manner that git can't recognize how to merge properly anymore. I will try to figure out what happened here. Please don't merge the translation branch to staging while I try figuring this out. Ok, the shit hit the fan. Apparently I was not fast enough, and somebody ran the staging-merge on the bad translation merge. Now master is borked. We have the following options: a) reset master and staging to one commit earlier, then try to repair the damage. That's what I try doing now --- did not work. remote: error: By default, deleting the current branch is denied, because the next remote: error: 'git clone' won't result in any file checked out, causing confusion. remote: error: remote: error: You can set 'receive.denyDeleteCurrent' configuration variable to remote: error: 'warn' or 'ignore' in the remote repository to allow deleting the remote: error: current branch, with or without a warning message. remote: error: remote: error: To squelch this message, you can set it to 'refuse'. remote: error: refusing to delete the current branch: refs/heads/master To ssh://git.sv.gnu.org/srv/git/lilypond.git ! [remote rejected] master (deletion of the current branch prohibited) b) I hate life. Please _don't_ push anything to the repository until I give the ok. This will likely take at least the rest of the day. I will have to figure out what went wrong where, and create a revert that does not cause more damage in the aftermath. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Bad translation merge
David Kastrup dak at gnu.org writes: I can reproduce the problems when merging. It would appear that the history of the translation branch got messed up at some point of time in a manner that git can't recognize how to merge properly anymore. I don't know if this can help you, but I noticed the following. Usually master is merged into lilypond/translation and then lilypond/translation is merged into master. If you look at the history about 11 days ago, you can see that master was merged into lilypond/translation, so far so good, but then it looks like lilypond/translation~0 was rebased on top of master, instead of merged into master. Hope this helps, Regards, Julien ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Bad translation merge
David On 7 March 2012 12:58, David Kastrup d...@gnu.org wrote: David Kastrup d...@gnu.org writes: David Kastrup d...@gnu.org writes: Hi, the recent translation merge apparently made some wrong choices when dealing with merge conflicts. Changes in staging have been overwritten in the following files: And that affects a lot more than just translations. I have removed that commit from origin/staging, and we'll have to investigate what happened. Francisco, do you remember the commands you used for merging translation into staging? I'll try repeating this on my own and see whether I can reproduce this. I can reproduce the problems when merging. It would appear that the history of the translation branch got messed up at some point of time in a manner that git can't recognize how to merge properly anymore. I will try to figure out what happened here. Please don't merge the translation branch to staging while I try figuring this out. Ok, the shit hit the fan. Apparently I was not fast enough, and somebody ran the staging-merge on the bad translation merge. Now master is borked. I won't be home until at least another patchy run (scheduled around 18:00 BST) and perhaps the one at midnight - depending when I get back. If it helps Graham (or someone) could disable my account at Savannah to stop patchy being able to push/merge. -- -- James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Bad translation merge
On Wed, Mar 07, 2012 at 01:58:24PM +0100, David Kastrup wrote: David Kastrup d...@gnu.org writes: I can reproduce the problems when merging. It would appear that the history of the translation branch got messed up at some point of time in a manner that git can't recognize how to merge properly anymore. I will try to figure out what happened here. Please don't merge the translation branch to staging while I try figuring this out. Ok, the shit hit the fan. Apparently I was not fast enough, and somebody ran the staging-merge on the bad translation merge. I think that James was correct to do this -- or rather James' computer correctly ran the cronjob scheduled for every six hours. I don't think that we should expect him to respond to emails within a few hours and cancel a cronjob; he needs to sleep, work, etc. As a general rule, I don't think that we should ever say don't try to merge staging. Instead, rename staging to broken-staging, and delete the staging branch. Unfortunately it's too late now, but hopefully next time we can avoid damage that way. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Bad translation merge
James pkx1...@gmail.com writes: David On 7 March 2012 12:58, David Kastrup d...@gnu.org wrote: David Kastrup d...@gnu.org writes: David Kastrup d...@gnu.org writes: Hi, the recent translation merge apparently made some wrong choices when dealing with merge conflicts. Changes in staging have been overwritten in the following files: And that affects a lot more than just translations. I have removed that commit from origin/staging, and we'll have to investigate what happened. Francisco, do you remember the commands you used for merging translation into staging? I'll try repeating this on my own and see whether I can reproduce this. I can reproduce the problems when merging. It would appear that the history of the translation branch got messed up at some point of time in a manner that git can't recognize how to merge properly anymore. I will try to figure out what happened here. Please don't merge the translation branch to staging while I try figuring this out. Ok, the shit hit the fan. Apparently I was not fast enough, and somebody ran the staging-merge on the bad translation merge. Now master is borked. I won't be home until at least another patchy run (scheduled around 18:00 BST) and perhaps the one at midnight - depending when I get back. If it helps Graham (or someone) could disable my account at Savannah to stop patchy being able to push/merge. If nobody pushes to staging, no staging-patchy will take action. So I don't think this is required. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Bad translation merge
Graham Percival gra...@percival-music.ca writes: On Wed, Mar 07, 2012 at 01:58:24PM +0100, David Kastrup wrote: David Kastrup d...@gnu.org writes: I can reproduce the problems when merging. It would appear that the history of the translation branch got messed up at some point of time in a manner that git can't recognize how to merge properly anymore. I will try to figure out what happened here. Please don't merge the translation branch to staging while I try figuring this out. Ok, the shit hit the fan. Apparently I was not fast enough, and somebody ran the staging-merge on the bad translation merge. I think that James was correct to do this -- or rather James' computer correctly ran the cronjob scheduled for every six hours. I don't think that we should expect him to respond to emails within a few hours and cancel a cronjob; he needs to sleep, work, etc. I was not trying to imply that James did something wrong. It would have been nice to avoid that headache, but I don't see that there was something wrong with our procedures. I was also not trying to imply that Francisco did anything wrong. I tried doing the same merge, and it went wrong the same way. I probably would not have pushed it, but only because I am better at spotting fishy things. Something bad happened in the history of the translation branch, and I have not tracked it down yet. As a general rule, I don't think that we should ever say don't try to merge staging. Instead, rename staging to broken-staging, and delete the staging branch. Unfortunately it's too late now, but hopefully next time we can avoid damage that way. Sure. I killed staging the moment I found that something was wrong with it. I just was not fast enough. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Bad translation merge
Julien Rioux julien.ri...@gmail.com writes: David Kastrup dak at gnu.org writes: I can reproduce the problems when merging. It would appear that the history of the translation branch got messed up at some point of time in a manner that git can't recognize how to merge properly anymore. I don't know if this can help you, but I noticed the following. Usually master is merged into lilypond/translation and then lilypond/translation is merged into master. If you look at the history about 11 days ago, you can see that master was merged into lilypond/translation, so far so good, but then it looks like lilypond/translation~0 was rebased on top of master, instead of merged into master. Ugh! That sounds bad. I'll have to investigate further. All the rebased commits would count as independent commits. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Bad translation merge
David Kastrup d...@gnu.org writes: David Kastrup d...@gnu.org writes: Hi, the recent translation merge apparently made some wrong choices when dealing with merge conflicts. Changes in staging have been overwritten in the following files: And that affects a lot more than just translations. I have removed that commit from origin/staging, and we'll have to investigate what happened. Francisco, do you remember the commands you used for merging translation into staging? I'll try repeating this on my own and see whether I can reproduce this. I can reproduce the problems when merging. It would appear that the history of the translation branch got messed up at some point of time in a manner that git can't recognize how to merge properly anymore. I will try to figure out what happened here. Please don't merge the translation branch to staging while I try figuring this out. Ok, here is a merge from master into translations that causes a large loss of functionality as opposed to its purportedly merged parent commit. Unfortunately, not just outside of Documentation, but also inside. Weird. Looking further. git diff --stat feb3b8d..17183f4a9696f2187128490a669895964959fa84 Documentation/changes.tely |8 - Documentation/contributor/introduction.itexi |4 +- Documentation/contributor/lsr-work.itexi | 25 --- Documentation/de/essay.tely|2 +- Documentation/de/extending.tely|2 +- Documentation/de/learning.tely |2 +- Documentation/de/learning/common-notation.itely|2 +- Documentation/de/learning/fundamental.itely|2 +- Documentation/de/learning/templates.itely |2 +- Documentation/de/learning/tweaks.itely |2 +- Documentation/de/notation.tely |2 +- Documentation/de/notation/changing-defaults.itely |2 +- Documentation/de/notation/expressive.itely |2 +- Documentation/de/notation/fretted-strings.itely|2 +- Documentation/de/notation/input.itely |2 +- Documentation/de/notation/pitches.itely|2 +- Documentation/de/notation/repeats.itely|2 +- Documentation/de/notation/rhythms.itely|2 +- Documentation/de/notation/simultaneous.itely |2 +- Documentation/de/notation/spacing.itely|2 +- Documentation/de/notation/staff.itely |2 +- Documentation/de/notation/text.itely |2 +- Documentation/de/notation/vocal.itely |2 +- Documentation/de/notation/wind.itely |2 +- Documentation/de/notation/world.itely |2 +- Documentation/de/translations.itexi| 136 +++--- Documentation/de/web.texi |2 +- Documentation/de/web/community.itexi |2 +- Documentation/de/web/download.itexi|2 +- Documentation/de/web/introduction.itexi|2 +- Documentation/de/web/manuals.itexi |2 +- Documentation/es/notation/percussion.itely |2 +- Documentation/es/notation/spacing.itely|9 +- Documentation/es/notation/staff.itely |2 +- Documentation/fr/included/helpus.itexi | 70 Documentation/fr/notation/changing-defaults.itely | 172 ++--- Documentation/fr/notation/input.itely |2 +- .../fr/notation/notation-appendices.itely | 14 ++- Documentation/fr/notation/percussion.itely |2 +- Documentation/fr/notation/spacing.itely|7 +- Documentation/fr/notation/wind.itely |2 +- Documentation/included/helpus.itexi| 11 +- Documentation/ly-examples/GNUmakefile |2 +- Documentation/notation/rhythms.itely | 30 +--- .../snippets/alternative-bar-numbering.ly |2 +- Documentation/snippets/alternative-breve-note.ly |2 +- ...centering-markup-on-note-heads-automatically.ly | 44 +++-- .../creating-metronome-marks-in-markup-mode.ly |2 +- .../customizing-fretboard-fret-diagrams.ly |6 +- ...ining-an-engraver-in-scheme-ambitus-engraver.ly | 45 +++-- ...play-bracket-with-only-one-staff-in-a-system.ly |2 +- .../snippets/formatting-lyrics-syllables.ly|7 +- Documentation/snippets/glissandi-can-skip-grobs.ly |2 +- Documentation/snippets/hymn-template.ly|1 - .../snippets/lyrics-old-spacing-settings.ly|2 +- Documentation/snippets/nesting-staves.ly |2 +- .../snippets/numbers-as-easy-note-heads.ly | 32 ++-- .../snippets/partcombine-and-autobeamoff.ly|2 - .../snippets/placement-of-right-hand-fingerings.ly |4 +- .../snippets/printing-marks-on-every-staff.ly |2 +-
Re: Bad translation merge
Julien Rioux julien.ri...@gmail.com writes: David Kastrup dak at gnu.org writes: I can reproduce the problems when merging. It would appear that the history of the translation branch got messed up at some point of time in a manner that git can't recognize how to merge properly anymore. I don't know if this can help you, but I noticed the following. Usually master is merged into lilypond/translation and then lilypond/translation is merged into master. It should be merged into _staging_ (which will eventually pass into master). I don't remember any chaos with regard to staging-master, so tampering with master was not likely a problem. If you look at the history about 11 days ago, you can see that master was merged into lilypond/translation, so far so good, but then it looks like lilypond/translation~0 was rebased on top of master, instead of merged into master. I see rebasing commits like commit 24f5f986998c23a1cbac15024d58ca6497093cce Author: Julien Rioux jri...@physics.utoronto.ca Commit: Francisco Vila francisco.v...@hispalinux.es Doc-de: Compilation fix for de/notation. commit 12cfe6bafb8589b0780df84fb36981994ee8793a Author: Till Paala till.ret...@gmx.de Commit: Francisco Vila francisco.v...@hispalinux.es Doc-de: update the noation manual, adding snippet translations which also appear in a version committed by their actual authors. That's definitely not good. But I don't see how this would explain the _loss_ of changes. Digging further. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Bad translation merge
Le 07/03/2012 15:29, David Kastrup disait : I see rebasing commits like commit 24f5f986998c23a1cbac15024d58ca6497093cce Author: Julien Riouxjri...@physics.utoronto.ca Commit: Francisco Vilafrancisco.v...@hispalinux.es Doc-de: Compilation fix for de/notation. commit 12cfe6bafb8589b0780df84fb36981994ee8793a Author: Till Paalatill.ret...@gmx.de Commit: Francisco Vilafrancisco.v...@hispalinux.es Doc-de: update the noation manual, adding snippet translations which also appear in a version committed by their actual authors. That's definitely not good. But I don't see how this would explain the _loss_ of changes. Digging further. I don't know if this can help, but I see many doubled commits in gitk, like Doc: fix link in all languages. which look like committed twice: f715a8eb30eb26b770b3888c1dcbbea00699e4eb Parent: 9ce85aa991ea6adb9f939d274ac439bf89daff67 (Doc: update snippets and run makelsr.) Enfant: 7b3a63a4a301a67a6812a73542d25016bfb32ebb (Doc: cosmethic change in snippet, translate and makelsr result.) Branche: lilypond/translation, remotes/origin/lilypond/translation, remotes/origin/master, remotes/origin/staging Suit: release/2.15.29-1 Précède: release/2.15.32-1 and 0058d34243ff16f1479acbed24b956e292e9dd3d Auteur: Francisco Vila francisco.v...@hispalinux.es 2012-02-23 19:24:00 Auteur du commit: Francisco Vila francisco.v...@hispalinux.es 2012-02-24 19:02:05 Parent: e7d1bb755923cbacf04075b7d319c574da28940d (Doc: update snippets and run makelsr.) Enfant: 04ed9273119ff228a003f7695b19ca34a4ba74dc (Doc: cosmethic change in snippet, translate and makelsr result.) Branche: lilypond/translation, remotes/origin/lilypond/translation, remotes/origin/master, remotes/origin/staging Suit: release/2.15.30-1 Précède: release/2.15.31-1 or Doc-fr: NR-2.5 percussion: Full review with 0c9027d3b2c5a61e44726f5ba4b831b3e10bed8f and 3517ba40f1a928edf0e06e88b77fc5ea2b62418d How may I help? Jean-Charles ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Bad translation merge
David Kastrup d...@gnu.org writes: Julien Rioux julien.ri...@gmail.com writes: David Kastrup dak at gnu.org writes: I can reproduce the problems when merging. It would appear that the history of the translation branch got messed up at some point of time in a manner that git can't recognize how to merge properly anymore. I don't know if this can help you, but I noticed the following. Usually master is merged into lilypond/translation and then lilypond/translation is merged into master. It should be merged into _staging_ (which will eventually pass into master). I don't remember any chaos with regard to staging-master, so tampering with master was not likely a problem. If you look at the history about 11 days ago, you can see that master was merged into lilypond/translation, so far so good, but then it looks like lilypond/translation~0 was rebased on top of master, instead of merged into master. I see rebasing commits like commit 24f5f986998c23a1cbac15024d58ca6497093cce Author: Julien Rioux jri...@physics.utoronto.ca Commit: Francisco Vila francisco.v...@hispalinux.es Doc-de: Compilation fix for de/notation. commit 12cfe6bafb8589b0780df84fb36981994ee8793a Author: Till Paala till.ret...@gmx.de Commit: Francisco Vila francisco.v...@hispalinux.es Doc-de: update the noation manual, adding snippet translations which also appear in a version committed by their actual authors. That's definitely not good. But I don't see how this would explain the _loss_ of changes. Digging further. I don't get it. If I take a look at scm (where some changes happened) with git log --date-order --graph --source origin origin/lilypond/translation scm then the graph outputs * commit 9d1520b21710bd22872010ae9aa4c4899014e9d4 origin |\ Merge: e995ed4 10af932 | | Author: Francisco Vila francisco.v...@hispalinux.es | | Date: Wed Mar 7 10:23:11 2012 +0100 | | | | Merge branch 'lilypond/translation' into staging | | | | Conflicts: | | Documentation/changes.tely | | Documentation/translations.itexi | | Documentation/web/news-front.itexi | | VERSION | | input/regression/layout-from.ly | | lily/context-def.cc | | * | commit e995ed461610c2bb9c9cd43eaa715905b8525b95 origin | | Author: David Kastrup d...@gnu.org | | Date: Sun Feb 26 19:16:00 2012 +0100 | | | | Allow music with layout instructions in output definitions. | | | | This allows things like | | | | \layout { \accidentalStyle modern } | | | | or | | | | \midi { \tempo 4 = 80 } | | | | to work as intended. | | * | commit 4d7cac2e94f7fb8c86c69c6d6fceff1ddfb545e4 origin | | Author: Carl Sorensen c_soren...@byu.edu | | Date: Sat Feb 18 09:49:56 2012 -0700 | | | | Set context properties to allow half-measure beaming in 3/4 (Issue 2246) | | | | Introduce beamWholeMeasure, which allows beaming of a whole measure of | | eighth notes in 3/4 time (but not beaming of a half measure, since it | | appears to be a 6/8 beaming). By default, set to #t. | | | | Introduce beamHalfMeasure, which allows beaming of a half measure of | | eighth notes in 3/4 time. By default, set to #f. | | | | A non-empty beamExceptions entry will override beamHalfMeasure and | | beamWholeMeasure, since user-specified rules should override defaults. | | | | Includes updated documentation in English docs, and a new regtest. No | | changes to translated docs. | | * | commit c37c6f39d18274ccac28ed42559681ea271cc496 origin | | Author: David Kastrup d...@gnu.org | | Date: Thu Feb 23 19:19:37 2012 +0100 | | | | Issue 2343: Faulty file-naming when outputting multiple \books | | * | commit 09814b549186893c265bcdf835edbe242f6354cf origin |/ Author: David Kastrup d...@gnu.org | Date: Sun Feb 26 11:23:39 2012 +0100 | | Implement ly:book? and ly:context-def? predicates | * commit 10af9324c6d94453857e10951c4f58043e9a9f11 origin/lilypond/translat ... So starting from the (unfortunately common) ancestor, the only branch that has actual changes in scm is master. Why does the merge then prefer the old versions? That does not make all that much sense to me. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Bad translation merge
Jean-Charles Malahieude lily...@orange.fr writes: Le 07/03/2012 15:29, David Kastrup disait : I see rebasing commits like commit 24f5f986998c23a1cbac15024d58ca6497093cce Author: Julien Riouxjri...@physics.utoronto.ca Commit: Francisco Vilafrancisco.v...@hispalinux.es Doc-de: Compilation fix for de/notation. commit 12cfe6bafb8589b0780df84fb36981994ee8793a Author: Till Paalatill.ret...@gmx.de Commit: Francisco Vilafrancisco.v...@hispalinux.es Doc-de: update the noation manual, adding snippet translations which also appear in a version committed by their actual authors. That's definitely not good. But I don't see how this would explain the _loss_ of changes. Digging further. I don't know if this can help, but I see many doubled commits in gitk, like Well yes, but the changes they introduce would not undo other changes. If I look at the symmetric difference of the parents of our current master merge, I see git log --stat --graph --source --date-order 744709d...ab45be2 * commit 744709d5ce7c67890c5c79f359f885a09cc26f27 744709d...ab45be2 | Author: Jan-Peter Voigt jp.vo...@gmx.de | Date: Fri Mar 2 09:54:20 2012 +0100 | | add ly:book-set-header! | | Add a scheme function ly:book-set-header! like ly:score-set-header! | | Function is copied from score-scheme.cc to book-scheme.cc, | setting public member var header_ in class Book. | | lily/book-scheme.cc | 13 + | 1 files changed, 13 insertions(+), 0 deletions(-) | * commit 2ccfd5a9f83819be67877522aeae7212fde3fefd 744709d...ab45be2 | Author: Mike Solomon m...@apollinemike.com | Date: Wed Mar 7 08:19:42 2012 +0100 | | Prevents segfault in Span_bar_stub_engraver through derived_mark. | | Makes sure that used contexts are not garbage collected and removes | of those that are from the axis_groups_ alist. | | lily/span-bar-stub-engraver.cc | 77 | 1 files changed, 62 insertions(+), 15 deletions(-) | * commit cc5223ac26a5713c5901c02edf2868c26be10542 744709d...ab45be2 | Author: Janek Warchoł janek.lilyp...@gmail.com | Date: Tue Mar 6 17:09:53 2012 +0100 | | Web: add GSoC ideas list | | A list of suggested projects for Google Summer of Code | students is necessary to participate in the program. | | Documentation/lilypond-texi2html.init |2 +- | Documentation/web/community.itexi | 199 + | 2 files changed, 200 insertions(+), 1 deletions(-) | | * commit ab45be2f0dd1b5eece042934682039ec4e99b271 ab45be2 | | Author: Jean-Charles Malahieude lily...@orange.fr | | Date: Tue Mar 6 17:14:41 2012 +0100 | | | | Doc-fr: enable Extending | | * master file | | * Scheme tutorial (first delivery) | | * programming interface (re-enable old material update skeleton) | | | | Documentation/fr/extending.tely| 78 + | | .../fr/extending/programming-interface.itely | 345 +++-- | | Documentation/fr/extending/scheme-tutorial.itely | 1649 | | 3 files changed, 1924 insertions(+), 148 deletions(-) | | * | commit 2bba3b65d5150ec62dda869bdb3a152b21a03504 744709d...ab45be2 | | Author: David Kastrup d...@gnu.org | | Date: Tue Mar 6 01:20:23 2012 +0100 | | | | Fix Issue 2380: formatting of lyrics, \versus and \respondum | | | | ly/gregorian.ly | 34 -- | | 1 files changed, 12 insertions(+), 22 deletions(-) | | * | commit 308c694ab361de67e261f5efa7b7e652dd4cf081 744709d...ab45be2 | | Author: Valentin Villenave valen...@villenave.net | | Date: Tue Mar 6 00:16:45 2012 +0100 | | | | Web: Announcement update for the new LilyPond Report | | | | I'm keeping more than three items on the front page | | so there's at least one Release Candidate still | | mentioned. | | | | Documentation/web/news-front.itexi | 19 --- | | Documentation/web/news.itexi |2 +- | | 2 files changed, 17 insertions(+), 4 deletions(-) | | * | commit fe2e679d876eba72077a9ced1b918ad330e79bb4 744709d...ab45be2 | | Author: Reinhold Kainhofer reinh...@kainhofer.com | | Date: Mon Mar 5 17:05:51 2012 + | | | | Make extract-texi-filenames ignore comments | | | | scripts/build/extract_texi_filenames.py |3 ++- | | 1 files changed, 2 insertions(+), 1 deletions(-) | | * | commit 418adb3cf974523a481a7b92975bea16e8b43472 744709d...ab45be2 | | Author: Graham Percival gra...@percival-music.ca | | Date: Mon Mar 5 12:53:58 2012 + | | | | Release: bump version. | | | | VERSION |4 ++-- | | 1 files changed, 2 insertions(+), 2 deletions(-) | | | * commit 3c62ac104645533873bba800f7b0f371089f535a ab45be2 | | Author: Yoshiki Sawada sawada.yosh...@gmail.com | | Date: Sun Mar 4 15:54:54 2012 +0900 | | | | Doc-ja: update LM and NR | | | | Doc-ja: update files of LM and NR
Re: Bad translation merge
- Original Message - From: Graham Percival gra...@percival-music.ca To: David Kastrup d...@gnu.org Cc: lilypond-devel@gnu.org Sent: Wednesday, March 07, 2012 1:22 PM Subject: Re: Bad translation merge On Wed, Mar 07, 2012 at 01:58:24PM +0100, David Kastrup wrote: David Kastrup d...@gnu.org writes: I can reproduce the problems when merging. It would appear that the history of the translation branch got messed up at some point of time in a manner that git can't recognize how to merge properly anymore. I will try to figure out what happened here. Please don't merge the translation branch to staging while I try figuring this out. Ok, the shit hit the fan. Apparently I was not fast enough, and somebody ran the staging-merge on the bad translation merge. I think that James was correct to do this -- or rather James' computer correctly ran the cronjob scheduled for every six hours. I don't think that we should expect him to respond to emails within a few hours and cancel a cronjob; he needs to sleep, work, etc. As a general rule, I don't think that we should ever say don't try to merge staging. Instead, rename staging to broken-staging, and delete the staging branch. Unfortunately it's too late now, but hopefully next time we can avoid damage that way. - Graham As an improvement to patchy, wouldn't it be better for patchy to test for a stop-patchy branch and abort if it finds one? Then all that would be necessary to suspend the cron job would be to create a branch with that name. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Bad translation merge
Le 07/03/2012 17:06, David Kastrup disait : Jean-Charles Malahieudelily...@orange.fr writes: Le 07/03/2012 15:29, David Kastrup disait : which also appear in a version committed by their actual authors. That's definitely not good. But I don't see how this would explain the _loss_ of changes. Digging further. I don't know if this can help, but I see many doubled commits in gitk, like In fact, there are 29 commits that I've isolated. I think Francisco might have got a problem on Feb. 24 (I don't know how what when why). Well yes, but the changes they introduce would not undo other changes. If I look at the symmetric difference of the parents of our current master merge, I see git log --stat --graph --source --date-order 744709d...ab45be2 [...] That all looks normalized. The duplicate commits are weeded out, and we have the two starting merges (starting from the same two commits) | * commit 17183f4a9696f2187128490a669895964959fa84 ab45be2 | Merge: caa20be feb3b8d | Author: Francisco Vilafrancisco.v...@hispalinux.es | Date: Thu Mar 1 15:38:35 2012 +0100 | | Merge branch 'master' into lilypond/translation and * commit e885a8cabc8335f1c46c48e92d4048e9d258cd10 744709d...ab45be2 Merge: feb3b8d caa20be Author: Francisco Vilafrancisco.v...@hispalinux.es Date: Thu Mar 1 13:59:42 2012 +0100 Merge branch 'lilypond/translation' into staging If we look at their difference, we see that while they start from the exact same two parent commits (just in a different order), they arrive at staggeringly different results: git diff --stat 17183f4a9696f2187128490a669895964959fa84 e885a8cabc8335f1c46c48e92d4048e9d258cd10 [...] 49 files changed, 549 insertions(+), 448 deletions(-) It turns out that 17183f is not actually a merge regarding the trees. Instead it is an exact copy of caa20be. That is something that happens when specifying a non-standard merge strategy. Or there was something else that went wrong that made git think that caa20be was everything that it needed. So | * commit 17183f4a9696f2187128490a669895964959fa84 ab45be2 | Merge: caa20be feb3b8d | Author: Francisco Vilafrancisco.v...@hispalinux.es | Date: Thu Mar 1 15:38:35 2012 +0100 | | Merge branch 'master' into lilypond/translation _thinks_ it merged master (feb3b8d at that point of time) into the translation tree and tells git that it did so. The other merge commit claims the same, and git reconciles those conflicting claims in a manner that wreaks havoc. I'll see whether I can get this fixed up. The problem is that we can't just revert the last merge we have at master: that essentially dials everything back to the state before the merge, except that git keeps thinking that everything that should ever come from the translation branch has already arrived, and will not reintegrate it next time. Dumb of me: even if the changes get reverted and re-committed on lilypond/translation, then merged again? Just a bad (?) guess. Jean-Charles ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Bad translation merge
On Wed, Mar 07, 2012 at 05:27:08PM -, Phil Holmes wrote: As an improvement to patchy, wouldn't it be better for patchy to test for a stop-patchy branch and abort if it finds one? Then all that would be necessary to suspend the cron job would be to create a branch with that name. No; if there's an emergency, deleting staging is no more effort than creating a new branch. Now, it could well be worth writing some test into patchy wherein if there's something suspicious in the git history for staging, it refuses to test it. Patches appreciated. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Bad translation merge
2012/3/7 David Kastrup d...@gnu.org: Hi, the recent translation merge apparently made some wrong choices when dealing with merge conflicts. Changes in staging have been overwritten in the following files: Documentation/snippets/centering-markup-on-note-heads-automatically.ly Documentation/snippets/defining-an-engraver-in-scheme-ambitus-engraver.ly Documentation/snippets/numbers-as-easy-note-heads.ly GNUmakefile.in input/regression/autobeam-3-4-rules.ly input/regression/multiple-time-sig-settings.ly lily/book-scheme.cc lily/parser.yy and a whole lot of others. Sorry for coming lately, I'm at work. This is what I know: I do not merge lilypond/translation into master. I do merge master into lilypond/translation and lilypond/translation into staging. I rebased by mistake (instead of merging) lilypond/translation into staging and my reasoning was: provided that staging does 'make make doc' and it has all the new work from translations, staging is not damaged in any way, for now. Translations are not damaged in any way, either. Then I waited until patchy merges into master, so I can now be sure that all those commits are 'upstream'. I could now safely merge master into translations as usual. When I will eventually merge again, duplicate commits should ideally combine in a single history. If not, and if we have any conflicts, I could merge with strategy recursive and option 'theirs'. That's what I did and worked fine apparently. All work is there, everything compiles well. Today, I merged translations into staging and some conflicts arose, but they were trivial, with the 'translations' part being empty, so it was clear to me that I should always choose the part with new content, namely the 'HEAD' part. That's what I manually did today. Only four or five files were affected. Then I checked 'make make doc' while in staging, with the merge conflicts resolved and commited. Everything looked fine, so I pushed. What did I do wrongly? (apart from the superfluous rebase) -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Bad translation merge
Graham Percival gra...@percival-music.ca writes: On Wed, Mar 07, 2012 at 05:27:08PM -, Phil Holmes wrote: As an improvement to patchy, wouldn't it be better for patchy to test for a stop-patchy branch and abort if it finds one? Then all that would be necessary to suspend the cron job would be to create a branch with that name. No; if there's an emergency, deleting staging is no more effort than creating a new branch. Wrong. I _did_ delete staging. But at that time, patchy had already started its testing work. If it checked for a stop-patchy or similar before it pushed the tested results, things would have been fine. But we don't need a separate branch for something like this. Patchy can just try doing a non-ff merge of origin/staging (on a detached HEAD?) before pushing the tested results (not the results of the non-ff merge which were not tested). If the non-ff merge of origin/staging _fails_, it means that whatever had been in origin/staging at the time the test started had been removed. I'll do something like that. Now, it could well be worth writing some test into patchy wherein if there's something suspicious in the git history for staging, it refuses to test it. Patches appreciated. What is suspicious? The suspicious part was that the merge of the translation branch changed a number of files outside of translation. The lesson I can see for Francisco is that he _never_ should need to resolve merge conflicts manually outside of the Documentation subtree. If something outside of Documentation calls for attention, he should not proceed but holler. And do the old git diff origin check, or at least git diff --stat origin check before pushing upstream and see that no non-Documentation files are tampered with. And if they are, complain. It is a really ungrateful job to work as translator and deal with a tool like git that is hard to really understand even for programmers. I know it's easy to say something like if there is something fishy when smelling the fishiness requires a trained nose. I still have no idea how this _started_ going wrong. Anyway, I am still working on finding a solution that does not require large sequences of cherry-picks to get the right state back out. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Bad translation merge
Francisco Vila paconet@gmail.com writes: 2012/3/7 David Kastrup d...@gnu.org: Hi, the recent translation merge apparently made some wrong choices when dealing with merge conflicts. Changes in staging have been overwritten in the following files: Documentation/snippets/centering-markup-on-note-heads-automatically.ly Documentation/snippets/defining-an-engraver-in-scheme-ambitus-engraver.ly Documentation/snippets/numbers-as-easy-note-heads.ly GNUmakefile.in input/regression/autobeam-3-4-rules.ly input/regression/multiple-time-sig-settings.ly lily/book-scheme.cc lily/parser.yy and a whole lot of others. Sorry for coming lately, I'm at work. This is what I know: I do not merge lilypond/translation into master. I do merge master into lilypond/translation and lilypond/translation into staging. Yes, I figured that this was not likely to be the cause of our problem. I rebased by mistake (instead of merging) lilypond/translation into staging and my reasoning was: provided that staging does 'make make doc' and it has all the new work from translations, staging is not damaged in any way, for now. Translations are not damaged in any way, either. The problem here is that the commits in translations are considered to be independent from the commits introducing the same changed in staging. That's bad for a variety of reasons. For example, if you revert one of the two commits in one branch and then merge a branch with the non-reverted cousin, that cousin is brought in again instead of being considered reverted. Don't rebase either origin and translation. Simple rule. Don't try being clever about it: being clever around git is a recipe for disaster. If you messed up your own repository (and that does not mean merely the state of the work tree, but the history of commits), don't push. Ask. We will figure out how to get it back into a nice state. Then I waited until patchy merges into master, so I can now be sure that all those commits are 'upstream'. I could now safely merge master into translations as usual. When I will eventually merge again, duplicate commits should ideally combine in a single history. If not, and if we have any conflicts, I could merge with strategy recursive and option 'theirs'. Well, there we are. It would appear that you used the merge strategy theirs rather than recursive + option theirs. The respective merge _claims_ to merge two commits but doesn't. It just takes the tree from theirs unchanged. At least this is what happened with the merge I traced to be faulty. If you try clever things, then at least check using git diff with the parents that they did what you think they did. That's what I did and worked fine apparently. How did you check? All work is there, Not according to git diff. The result of the merge is identical to _one_ of the parents. everything compiles well. Well, it would. The work tree was identical to something that compiled previously. Today, I merged translations into staging and some conflicts arose, but they were trivial, with the 'translations' part being empty, so it was clear to me that I should always choose the part with new content, namely the 'HEAD' part. That's what I manually did today. Only four or five files were affected. Files that were _not_ part of the Documentation tree. If you get conflicts in files and directories you did not work on in the translation branch, something is wrong. Then I checked 'make make doc' while in staging, with the merge conflicts resolved and commited. Everything looked fine, so I pushed. What did I do wrongly? (apart from the superfluous rebase) The rebase _is_ creating trouble when we have to revert things. It also makes it harder for merge resolution to work. But the thing that _really_ messed up the translation branch was the merge with strategy theirs or ours. You need to check the results of clever merges with git diff against its parents. That stuff compiles is _no_ guarantee that a merge happened. In fact, the only way to have compiling fail given two branches that compiled on their own is _when_ an actual merge happened. So compiling/testing is not helpful for checking the integrity of a merge. Only for checking the integrity of the result. You have to use git diff (and git diff --stat) against the parents to check a merge for plausability. Yes, it is an ungrateful job as translation master: other people can work for years without ever having to push a merge commit. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Bad translation merge
David Kastrup d...@gnu.org writes: Don't rebase either origin and translation. Simple rule. Don't try being clever about it: being clever around git is a recipe for disaster. If you messed up your own repository (and that does not mean merely the state of the work tree, but the history of commits), don't push. Ask. We will figure out how to get it back into a nice state. Then I waited until patchy merges into master, so I can now be sure that all those commits are 'upstream'. I could now safely merge master into translations as usual. When I will eventually merge again, duplicate commits should ideally combine in a single history. If not, and if we have any conflicts, I could merge with strategy recursive and option 'theirs'. Well, there we are. It would appear that you used the merge strategy theirs rather than recursive + option theirs. The respective merge _claims_ to merge two commits but doesn't. It just takes the tree from theirs unchanged. At least this is what happened with the merge I traced to be faulty. Ok, I take that back: this merge might not necessarily be the exact cause of the trouble. If you merge an original branch again after you already rebased it, the merge conflict resolution would essentially resolve to what the rebased branch already had. So that merge resolution would indeed look like a one-sided merge strategy in its outcome. Digging further. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Bad translation merge
David Kastrup d...@gnu.org writes: David Kastrup d...@gnu.org writes: Don't rebase either origin and translation. Simple rule. Don't try being clever about it: being clever around git is a recipe for disaster. If you messed up your own repository (and that does not mean merely the state of the work tree, but the history of commits), don't push. Ask. We will figure out how to get it back into a nice state. Then I waited until patchy merges into master, so I can now be sure that all those commits are 'upstream'. I could now safely merge master into translations as usual. When I will eventually merge again, duplicate commits should ideally combine in a single history. If not, and if we have any conflicts, I could merge with strategy recursive and option 'theirs'. Well, there we are. It would appear that you used the merge strategy theirs rather than recursive + option theirs. The respective merge _claims_ to merge two commits but doesn't. It just takes the tree from theirs unchanged. At least this is what happened with the merge I traced to be faulty. Ok, I take that back: this merge might not necessarily be the exact cause of the trouble. If you merge an original branch again after you already rebased it, the merge conflict resolution would essentially resolve to what the rebased branch already had. So that merge resolution would indeed look like a one-sided merge strategy in its outcome. Digging further. man git-rebase has a few interesting bits: -m, --merge Use merging strategies to rebase. When the recursive (default) merge strategy is used, this allows rebase to be aware of renames on the upstream side. Note that a rebase merge works by replaying each commit from the working branch on top of the upstream branch. Because of this, when a merge conflict happens, the side reported as ours is the so-far rebased series, starting with upstream, and theirs is the working branch. In other words, the sides are swapped. Also -p, --preserve-merges Instead of ignoring merges, try to recreate them. This uses the --interactive machinery internally, but combining it with the --interactive option explicitly is generally not a good idea unless you know what you are doing (see BUGS below). Merge commits are usually _ignored_ when rebasing. This includes merges from master into translation. If you rebased the translation branch on an _old_ version of master (namely on your local master rather than origin/master). Hm, no, I still don't get what happened. I need to figure out more. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Bad translation merge
Hi, one question: we can checkout a commit before merge commit and thus fix master? So, the main problem is how to fix translation properly? Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Bad translation merge
Janek Warchoł janek.lilyp...@gmail.com writes: Hi, one question: we can checkout a commit before merge commit and thus fix master? So, the main problem is how to fix translation properly? We can't fix master that easily. You'll get a nice working tree in that manner, but you can't push that to master. And the next time you merge translations into master, they will break everything again. I've created a rebased branch containing all the commits that were dropped in the faulty merge, and merged that into translation (the result is at dev/translation). I then merged that back into master (of course, having to undo Francisco's conflict resolution, partly manually resolved merge conflicts, partly reremoving stuff that was removed in master commits and resuscitated in manual merge resolution). The result of that is in /dev/staging. Now I don't have sufficient resources to continue reasonably fast. Somebody needs to do make test-baseline on the last commit before the merge (should be origin~1), and then a make check on the stuff in /dev/staging. This should turn up no differences (except for those caused by translation). If that's ok, we can push this to staging proper and see how Patchy fares with it. And somebody should check the diff between dev/translation and lilypond/translation and make sure that those differences are not undoing any work by the translators. They shouldn't, but I am not totally sure. I hope I don't cause extra work here. There seem to be a lot of changes in committish info. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Bad translation merge
On Wed, Mar 7, 2012 at 10:47 PM, David Kastrup d...@gnu.org wrote: Janek Warchoł janek.lilyp...@gmail.com writes: Hi, one question: we can checkout a commit before merge commit and thus fix master? So, the main problem is how to fix translation properly? We can't fix master that easily. You'll get a nice working tree in that manner, but you can't push that to master. And the next time you merge translations into master, they will break everything again. ok, thanks for explanation. I've created a rebased branch containing all the commits that were dropped in the faulty merge, and merged that into translation (the result is at dev/translation). I then merged that back into master (of course, having to undo Francisco's conflict resolution, partly manually resolved merge conflicts, partly reremoving stuff that was removed in master commits and resuscitated in manual merge resolution). The result of that is in /dev/staging. Now I don't have sufficient resources to continue reasonably fast. Somebody needs to do make test-baseline on the last commit before the merge (should be origin~1), and then a make check on the stuff in /dev/staging. This should turn up no differences (except for those caused by translation). If that's ok, we can push this to staging proper and see how Patchy fares with it. maybe James can do that? I have to go to sleep now and tomorrow i'll be busy all day, unfortunately. thanks, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Bad translation merge
David Kastrup d...@gnu.org writes: Francisco Vila paconet@gmail.com writes: I rebased by mistake (instead of merging) lilypond/translation into staging and my reasoning was: provided that staging does 'make make doc' and it has all the new work from translations, staging is not damaged in any way, for now. Except that the work of the last few weeks in master may be gone. master compiled a few weeks ago just fine, so compiling is a poor test for integrity. Anyway, when in doubt, don't reason. Just make sure that you are in the branch you started with 15 minutes ago, then do git reset --hard HEAD@{15 minutes ago} and then do it the stupid way. Yes, you can tell git literally to go back to what HEAD was 15 minutes ago. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Bad translation merge
Janek Warchoł janek.lilyp...@gmail.com writes: On Wed, Mar 7, 2012 at 10:47 PM, David Kastrup d...@gnu.org wrote: I've created a rebased branch containing all the commits that were dropped in the faulty merge, and merged that into translation (the result is at dev/translation). I then merged that back into master (of course, having to undo Francisco's conflict resolution, partly manually resolved merge conflicts, partly reremoving stuff that was removed in master commits and resuscitated in manual merge resolution). The result of that is in /dev/staging. Now I don't have sufficient resources to continue reasonably fast. Somebody needs to do make test-baseline on the last commit before the merge (should be origin~1), and then a make check on the stuff in /dev/staging. This should turn up no differences (except for those caused by translation). If that's ok, we can push this to staging proper and see how Patchy fares with it. maybe James can do that? I have to go to sleep now and tomorrow i'll be busy all day, unfortunately. Well, somebody will likely be me, of course. Sleep is overrated. make check is not all that slow, and I can leave the full doc build to Patchy (assuming he is still on regular duty: there is actually no reason why he shouldn't be). That leaves the translations. Now we can reset them if needed, but I prefer not to do that since rewinding published history is a nuisance, and I don't really want to force the translators to mess more with their repositories than necessary. I suppose I'll push that thing shortly and hope for the best. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Bad translation merge
David Kastrup d...@gnu.org writes: Well, somebody will likely be me, of course. Sleep is overrated. make check is not all that slow, and I can leave the full doc build to Patchy (assuming he is still on regular duty: there is actually no reason why he shouldn't be). That leaves the translations. Now we can reset them if needed, but I prefer not to do that since rewinding published history is a nuisance, and I don't really want to force the translators to mess more with their repositories than necessary. I suppose I'll push that thing shortly and hope for the best. I pushed both the translation branch as well as staging. The fixed translation branch is merged into staging, but I have not merged staging (hopefully master soon: I think midnight GMT is in 20 minutes, and that should trigger James' patchy) back into translation. Translators should first check that lilypond/translation is in a consistent state (I am doubtful about the committishes). Once it is considered fine, one can merge the (hopefully) new master back, and the two should be reasonably synced again. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Bad translation merge
Hello, On 7 March 2012 23:42, David Kastrup d...@gnu.org wrote: David Kastrup d...@gnu.org writes: Well, somebody will likely be me, of course. Sleep is overrated. make check is not all that slow, and I can leave the full doc build to Patchy (assuming he is still on regular duty: there is actually no reason why he shouldn't be). That leaves the translations. Now we can reset them if needed, but I prefer not to do that since rewinding published history is a nuisance, and I don't really want to force the translators to mess more with their repositories than necessary. I suppose I'll push that thing shortly and hope for the best. I pushed both the translation branch as well as staging. The fixed translation branch is merged into staging, but I have not merged staging (hopefully master soon: I think midnight GMT is in 20 minutes, and that should trigger James' patchy) back into translation. Translators should first check that lilypond/translation is in a consistent state (I am doubtful about the committishes). Once it is considered fine, one can merge the (hopefully) new master back, and the two should be reasonably synced again. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel Do you still want me to keep patchy going? I'll pause it for now and if I hear nothing I'll kick it off. Or do you want me to do a make/make doc on something? I'll be around for the next 30 mins or so (until around 00:30 BST). Regards -- -- James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Bad translation merge
James pkx1...@gmail.com writes: On 7 March 2012 23:42, David Kastrup d...@gnu.org wrote: David Kastrup d...@gnu.org writes: Well, somebody will likely be me, of course. Sleep is overrated. make check is not all that slow, and I can leave the full doc build to Patchy (assuming he is still on regular duty: there is actually no reason why he shouldn't be). That leaves the translations. Now we can reset them if needed, but I prefer not to do that since rewinding published history is a nuisance, and I don't really want to force the translators to mess more with their repositories than necessary. I suppose I'll push that thing shortly and hope for the best. I pushed both the translation branch as well as staging. The fixed translation branch is merged into staging, but I have not merged staging (hopefully master soon: I think midnight GMT is in 20 minutes, and that should trigger James' patchy) back into translation. Translators should first check that lilypond/translation is in a consistent state (I am doubtful about the committishes). Once it is considered fine, one can merge the (hopefully) new master back, and the two should be reasonably synced again. Do you still want me to keep patchy going? I'll pause it for now and if I hear nothing I'll kick it off. Huh? Why pause? I wrote hopefully master soon. Just let the beast run as scheduled. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Bad translation merge
hello, On 8 March 2012 00:04, David Kastrup d...@gnu.org wrote: James pkx1...@gmail.com writes: On 7 March 2012 23:42, David Kastrup d...@gnu.org wrote: David Kastrup d...@gnu.org writes: Well, somebody will likely be me, of course. Sleep is overrated. make check is not all that slow, and I can leave the full doc build to Patchy (assuming he is still on regular duty: there is actually no reason why he shouldn't be). That leaves the translations. Now we can reset them if needed, but I prefer not to do that since rewinding published history is a nuisance, and I don't really want to force the translators to mess more with their repositories than necessary. I suppose I'll push that thing shortly and hope for the best. I pushed both the translation branch as well as staging. The fixed translation branch is merged into staging, but I have not merged staging (hopefully master soon: I think midnight GMT is in 20 minutes, and that should trigger James' patchy) back into translation. Translators should first check that lilypond/translation is in a consistent state (I am doubtful about the committishes). Once it is considered fine, one can merge the (hopefully) new master back, and the two should be reasonably synced again. Do you still want me to keep patchy going? I'll pause it for now and if I hear nothing I'll kick it off. Huh? Why pause? I wrote hopefully master soon. Just let the beast run as scheduled. OK it's off and running. I'll stick about for the next 20 minutes to see what happens. -- -- James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Bad translation merge
Hello, On 8 March 2012 00:04, David Kastrup d...@gnu.org wrote: ... Huh? Why pause? I wrote hopefully master soon. Just let the beast run as scheduled. This is what it reports as it started (just FYI) --snip-- emote: Counting objects: 272, done. remote: Compressing objects: 100% (30/30), done. remote: Total 169 (delta 139), reused 169 (delta 139) Receiving objects: 100% (169/169), 21.91 KiB, done. Resolving deltas: 100% (139/139), completed with 79 local objects. From ssh://git.sv.gnu.org/srv/git/lilypond * [new branch] dev/staging - origin/dev/staging * [new branch] dev/translation - origin/dev/translation 32b9cd0..5697144 lilypond/translation - origin/lilypond/translation 9d1520b..2944a83 staging- origin/staging Branch test-master-lock set up to track remote branch master from origin. Branch test-staging set up to track remote branch staging from origin. Initialized empty Git repository in /home/james/lilypond-git/build/.git/ Updating 9d1520b..2944a83 Fast-forward Documentation/contributor/introduction.itexi |4 +- Documentation/contributor/lsr-work.itexi | 25 +++ Documentation/de/notation/spacing.itely|2 +- Documentation/included/helpus.itexi| 11 +- Documentation/ly-examples/GNUmakefile |2 +- Documentation/notation/rhythms.itely | 30 +++- .../snippets/alternative-bar-numbering.ly |2 +- Documentation/snippets/alternative-breve-note.ly |2 +- ...centering-markup-on-note-heads-automatically.ly | 44 ++--- .../creating-metronome-marks-in-markup-mode.ly |2 +- .../customizing-fretboard-fret-diagrams.ly |6 +- ...ining-an-engraver-in-scheme-ambitus-engraver.ly | 45 ++--- ...play-bracket-with-only-one-staff-in-a-system.ly |2 +- .../snippets/formatting-lyrics-syllables.ly|7 +- Documentation/snippets/glissandi-can-skip-grobs.ly |2 +- Documentation/snippets/hymn-template.ly|1 + .../snippets/lyrics-old-spacing-settings.ly|2 +- Documentation/snippets/nesting-staves.ly |2 +- .../snippets/numbers-as-easy-note-heads.ly | 32 ++-- .../snippets/partcombine-and-autobeamoff.ly|2 + .../snippets/placement-of-right-hand-fingerings.ly |4 +- .../snippets/printing-marks-on-every-staff.ly |2 +- ...etronome-and-rehearsal-marks-below-the-staff.ly |2 +- Documentation/snippets/strict-beat-beaming.ly |2 +- .../snippets/woodwind-diagrams-key-lists.ly|2 +- Documentation/web/community.itexi |6 +- GNUmakefile.in |5 +- input/regression/autobeam-3-4-rules.ly | 24 +++ input/regression/multiple-time-sig-settings.ly |4 +- input/regression/rest-on-nonstandard-staff.ly |5 + lily/book-scheme.cc|4 + lily/parser.yy |2 - lily/rest.cc | 31 ++- ly/engraver-init.ly|7 +- ly/event-listener.ly | 26 ++-- ly/init.ly |2 - ly/music-functions-init.ly |8 +- make/lilypond-book-vars.make |2 +- make/ly-rules.make |2 +- make/midi-rules.make |2 +- ps/music-drawing-routines.ps | 21 ++- scm/auto-beam.scm | 48 - scm/define-context-properties.scm |4 + scm/lily-library.scm | 34 +++- scm/lily.scm |4 +- scm/time-signature-settings.scm| 17 +- scripts/build/mutopia-index.py | 197 stepmake/stepmake/texinfo-rules.make |4 +- 48 files changed, 315 insertions(+), 381 deletions(-) create mode 100644 input/regression/autobeam-3-4-rules.ly delete mode 100644 scripts/build/mutopia-index.py Total 0 (delta 0), reused 0 (delta 0) To /home/james/lilypond-git/ 9d1520b..2944a83 test-master-lock - test-master-lock --snip-- -- -- James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Bad translation merge
James pkx1...@gmail.com writes: Hello, On 8 March 2012 00:04, David Kastrup d...@gnu.org wrote: ... Huh? Why pause? I wrote hopefully master soon. Just let the beast run as scheduled. This is what it reports as it started (just FYI) --snip-- emote: Counting objects: 272, done. remote: Compressing objects: 100% (30/30), done. remote: Total 169 (delta 139), reused 169 (delta 139) Receiving objects: 100% (169/169), 21.91 KiB, done. Resolving deltas: 100% (139/139), completed with 79 local objects. From ssh://git.sv.gnu.org/srv/git/lilypond * [new branch] dev/staging - origin/dev/staging * [new branch] dev/translation - origin/dev/translation 32b9cd0..5697144 lilypond/translation - origin/lilypond/translation 9d1520b..2944a83 staging- origin/staging Branch test-master-lock set up to track remote branch master from origin. Branch test-staging set up to track remote branch staging from origin. Initialized empty Git repository in /home/james/lilypond-git/build/.git/ Updating 9d1520b..2944a83 Fast-forward Documentation/contributor/introduction.itexi |4 +- Documentation/contributor/lsr-work.itexi | 25 +++ Documentation/de/notation/spacing.itely|2 +- Documentation/included/helpus.itexi| 11 +- Documentation/ly-examples/GNUmakefile |2 +- Documentation/notation/rhythms.itely | 30 +++- .../snippets/alternative-bar-numbering.ly |2 +- Documentation/snippets/alternative-breve-note.ly |2 +- ...centering-markup-on-note-heads-automatically.ly | 44 ++--- .../creating-metronome-marks-in-markup-mode.ly |2 +- .../customizing-fretboard-fret-diagrams.ly |6 +- ...ining-an-engraver-in-scheme-ambitus-engraver.ly | 45 ++--- ...play-bracket-with-only-one-staff-in-a-system.ly |2 +- .../snippets/formatting-lyrics-syllables.ly|7 +- Documentation/snippets/glissandi-can-skip-grobs.ly |2 +- Documentation/snippets/hymn-template.ly|1 + .../snippets/lyrics-old-spacing-settings.ly|2 +- Documentation/snippets/nesting-staves.ly |2 +- .../snippets/numbers-as-easy-note-heads.ly | 32 ++-- .../snippets/partcombine-and-autobeamoff.ly|2 + .../snippets/placement-of-right-hand-fingerings.ly |4 +- .../snippets/printing-marks-on-every-staff.ly |2 +- ...etronome-and-rehearsal-marks-below-the-staff.ly |2 +- Documentation/snippets/strict-beat-beaming.ly |2 +- .../snippets/woodwind-diagrams-key-lists.ly|2 +- Documentation/web/community.itexi |6 +- GNUmakefile.in |5 +- input/regression/autobeam-3-4-rules.ly | 24 +++ input/regression/multiple-time-sig-settings.ly |4 +- input/regression/rest-on-nonstandard-staff.ly |5 + lily/book-scheme.cc|4 + lily/parser.yy |2 - lily/rest.cc | 31 ++- ly/engraver-init.ly|7 +- ly/event-listener.ly | 26 ++-- ly/init.ly |2 - ly/music-functions-init.ly |8 +- make/lilypond-book-vars.make |2 +- make/ly-rules.make |2 +- make/midi-rules.make |2 +- ps/music-drawing-routines.ps | 21 ++- scm/auto-beam.scm | 48 - scm/define-context-properties.scm |4 + scm/lily-library.scm | 34 +++- scm/lily.scm |4 +- scm/time-signature-settings.scm| 17 +- scripts/build/mutopia-index.py | 197 stepmake/stepmake/texinfo-rules.make |4 +- 48 files changed, 315 insertions(+), 381 deletions(-) create mode 100644 input/regression/autobeam-3-4-rules.ly delete mode 100644 scripts/build/mutopia-index.py Total 0 (delta 0), reused 0 (delta 0) To /home/james/lilypond-git/ 9d1520b..2944a83 test-master-lock - test-master-lock Quite as expected. It has a _lot_ of damage to undo from that merge commit. I have checked the versions, and it would appear that once translation has been checked _and_ the new master merged into it _and_ back into staging again, the Bug Squad will need to reverify all issues with Fixed_2_15_31 or later _textually_ (meaning that they need to check that the changes are in the work tree, not that the commit is in the history: the commits will be there several times under different commit ids, and some of the commit history is a lie). Yes, that's annoying. But it