Re: Issue 2376: Automatic footnotes on \null markups causes unexpected results (issue 5755058)
http://codereview.appspot.com/5755058/diff/1/lily/page-layout-problem.cc File lily/page-layout-problem.cc (right): http://codereview.appspot.com/5755058/diff/1/lily/page-layout-problem.cc#newcode343 lily/page-layout-problem.cc:343: return footnote_separator; Uh, Mike? You call a Scheme function for calculating a stencil, then unsmob the stencil and return a pointer to the unsmobbbed entity. The SCM expression is not kept around in any manner. How on Earth is the Scheme garbage collector supposed to guess that the Stencil for which you have retained a pointer but no referring SCM is not supposed to be collected right away? That's not just buggy code, it is also a function call interface that can't be made to work. You can't return pointers to unsmobbed entities for which no SCM reference is retained anywhere. Given the level and amount of code you write, it might be worth investing the time rereading the garbage collection chapter of the Guile manual. I'll be preparing a fix for this one as well. http://codereview.appspot.com/5755058/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
financial support according to The Lilypond Report #24
Hi David, I am willing to support the development of LilyPond financially with small amount of money regularly. I am not sure I understand your payment plans. For example (quoting from http://news.lilynet.net/?The-LilyPond-Report-24): - [*Lifesaver*] Minimum €0, cap €250 per month, monthly target €800. That means that if the target (which basically allows me to postpone my decision to work elsewhere) is reached with everybody’s minimum already, you are not billed. This is the option to pick if you don’t want to support a single person as much as keep the LilyPond project from losing me. You do what is necessary to avoid my leaving, but nothing else. Yes, it will be annoying if it turns out you have to pay the cap more than once, but it will also be annoying for me not even to afford survival in spite of highly qualified work. Does it mean, that people should express their interest to keep the LilyPond project from losing you and you will let them know according to the number of payers how much should everyone each particular month pay? Marek Klein http://gregoriana.sk ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: financial support according to The Lilypond Report #24
Marek Klein ma...@gregoriana.sk writes: Hi David, I am willing to support the development of LilyPond financially with small amount of money regularly. I am not sure I understand your payment plans. For example (quoting from http://news.lilynet.net/?The-LilyPond-Report-24): * [Lifesaver] Minimum €0, cap €250 per month, monthly target €800. That means that if the target (which basically allows me to postpone my decision to work elsewhere) is reached with everybody’s minimum already, you are not billed. This is the option to pick if you don’t want to support a single person as much as keep the LilyPond project from losing me. You do what is necessary to avoid my leaving, but nothing else. Yes, it will be annoying if it turns out you have to pay the cap more than once, but it will also be annoying for me not even to afford survival in spite of highly qualified work. Does it mean, that people should express their interest to keep the LilyPond project from losing you Well, the means of expression required here is rather blandly money. and you will let them know according to the number of payers how much should everyone each particular month pay? That's it more or less, except that I tell people on the first each month how much they _overpayed_ last month according to the payments that got in, so that they can subtract that from next month's payment. For one thing, I have no way to know in advance how many spontaneous payments will arrive. For another, it turns out that it is hard to guess how many people will actually stick to their promises (I don't quite get the point in announcing support, exchanging mails and phone calls and getting the required banking data, then dropping off the face of the Earth, but yes, it happens more often than I understand), and of course I have no standing to make them. So if you are opting for Lifesaver, you pay €250 on the first month (unless the total carryover from last month already exceeds €800, in which case you get into the program for free until it doesn't). Whatever is not used up in the first month due to other people contributing to the goal of €800 is carried over into the next month, so you'll have to pay less. Of course, right now it does not look all that likely that there will be much of a carryover. In March, there have been some one-time payments already due to the article, and there will probably be a few more. I have not ruled out yet that March could indeed be good for €800. But as monthly payments, I have so far secured €100, and I consider it likely that the one-time payments will drop off again in the next months. So if you want to commit to a regular plan, you should realistically pick a cap that you can sustain for more than just a few months: larger one-time payments are nice, but smaller sustainable payments tend to add up in the long run, and _feel_ like they are less of an effort, so they are more likely to continue. Does that answer your question? Thanks -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Bad translation merge
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. git diff --stat 744709d..9d1520b21710bd22872010ae9aa4c4899014e9d4 shows Documentation/contributor/introduction.itexi |4 +- Documentation/contributor/lsr-work.itexi | 25 - Documentation/de/search-box.ihtml | 15 +- Documentation/de/usage.tely|2 +- Documentation/de/usage/external.itely | 104 ++- Documentation/de/usage/lilypond-book.itely | 217 ++- Documentation/de/usage/running.itely | 242 ++-- Documentation/de/usage/updating.itely | 12 +- Documentation/fr/extending.tely| 78 + .../fr/extending/programming-interface.itely | 345 +++-- Documentation/fr/extending/scheme-tutorial.itely | 1649 Documentation/included/helpus.itexi| 11 +- Documentation/ja/learning.tely |2 +- Documentation/ja/learning/templates.itely |3 +- Documentation/ja/learning/tweaks.itely | 294 ++-- Documentation/ja/notation.tely |4 +- Documentation/ja/notation/percussion.itely |2 +- Documentation/ja/notation/pitches.itely| 82 +- Documentation/ja/notation/rhythms.itely| 414 -- Documentation/ja/notation/wind.itely |2 +- Documentation/ly-examples/GNUmakefile |2 +- Documentation/notation/rhythms.itely | 30 +- ...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|9 - Documentation/snippets/hymn-template.ly|1 - 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 +- .../snippets/woodwind-diagrams-key-lists.ly|2 +- Documentation/translations.itexi |3 +- 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 +- 60 files changed, 3207 insertions(+), 949 deletions(-) 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. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Gets vertical skylines from grob stencils (issue 5626052)
2012/3/6 Janek Warchoł janek.lilyp...@gmail.com On Tue, Mar 6, 2012 at 11:48 PM, Joe Neeman joenee...@gmail.com wrote: 2012/3/6 janek.lilyp...@gmail.com Mike all, i did a quick compile with patchset 36 and unfortunately didn't notice significant speedups from previous version. Could you try the dev/jneem branch in git? It has some optimizations. If that doesn't help, could you please send me some of the worst files? They look better indeed time-wise. As for the output, i've only did a quick look and noticed this: why you deleted horizontal padding? This results in mf at the bottom right of 1st page of Tota pulchra to jump into above lyrics. The way skyline padding was being done made the code very messy. Also, padding was being added in multiple places, so some things were getting extra padding. However, the capability for doing padding is still there (for example, with the outside-staff-horizon-padding property). I agree, though, that the defaults will need to be revisited. Actually, small/zero horizontal padding might give better results in some places, but that needs thorough investigation. Something that, FWIW, never happened with the previous defaults. A bunch of the lines I deleted had comments like // TODO: figure out what horizon_padding should be Cheers, Joe ___ 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: 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: Issue 2376: Automatic footnotes on \null markups causes unexpected results (issue 5755058)
On Mar 7, 2012, at 8:48 AM, d...@gnu.org wrote: Given the level and amount of code you write, it might be worth investing the time rereading the garbage collection chapter of the Guile manual. You're right that I know nothing about guile's garbage collection...it'd help to know this. I'll investigate. It'd also be good to do a little write-up for the CG w/ garbage collection dos and don'ts in the LilyPond base (i.e. what mark_smob, derived_mark, unsmob_thingee, smobbed_copy, self_scm co. all mean). Cheers, MS ___ 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: Issue 2376: Automatic footnotes on \null markups causes unexpected results (issue 5755058)
m...@apollinemike.com m...@apollinemike.com writes:
On Mar 7, 2012, at 8:48 AM, d...@gnu.org wrote:
Given the level and amount of code you write, it might be worth
investing the time rereading the garbage collection chapter of the Guile
manual.
You're right that I know nothing about guile's garbage
collection...it'd help to know this.
In a nutshell: if an SCM object is not referenced, the garbage collector
is free to throw it and its contents away.
As a reference counts:
a) getting marked using scm_gc_mark during garbage collection (mark
phase) because another referenced object does this. All Scheme data
structures do that to their members (with the exception of weak parts
of a hash table). Our own Scheme objects need to do this to their
contents via their own mark subroutines (like derived_mark).
b) getting permanently protected. Many of our own data structures
when created with new start out in protected state (since they don't
have an SCM referencing them yet, hard to avoid) and convert into SCM
via a call to unprotect () once they are properly initialized so that
calling their mark routine does not cause uninitialized garbage to be
marked.
c) having an SCM type variable in the stack referencing it. This is a
somewhat shaky operation since the compiler may optimize variables away
when they are no longer needed. If that is a concern, you can use
scm_remember_upto_here_1 and its cousins to keep the SCM variables
alive.
Strictly speaking, code like
Stencil *s = unsmob_stencil (Text_interface::interpret_markup (layout, pro
if (!s)
{
programming_error (Your numbering function needs to return a stencil.
footnote_number_markups.push_back (SCM_EOL);
footnote_number_stencils.push_back (Stencil (Box (Interval (0, 0), Int
}
else
{
footnote_number_markups.push_back (markup);
footnote_number_stencils.push_back (*s);
}
counter++;
is already borderline. From the time of unsmob_stencil, the returned
markup is no longer protected as an SCM object. If
footnote_number_markups.push_back were to cause Scheme garbage
collection to trigger, *s would likely already be trashed.
If we get a multithreaded garbage collector at one point of time, you
first need to assign the result of interpret_markup to an SCM variable
and put an scm_remember_upto_here_1 on this variable after the last use
of the unsmobbed stencil pointer. Of course, if the unsmobbed object is
part of a larger protected data structure, you need not worry all that
much. Much of the Grob * in our code base is rather laissez-faire about
protection because the grobs are usually registered somewhere else. For
example, Grob_info does not bother protecting its contents at all if I
remember correctly because it assumes that they will live longer than
the Grob_info because of unrelated reasons.
I'll investigate. It'd also be good to do a little write-up for the
CG w/ garbage collection dos and don'ts in the LilyPond base
(i.e. what mark_smob, derived_mark, unsmob_thingee, smobbed_copy,
self_scm co. all mean).
A smobbed_copy is a Scheme object with the same contents as the original
but not using it (and thus also not protecting it from collection). A
self_scm is a Scheme object referencing the original. unsmob gives a
pointer to the unwrapped object. mark_smob is called during the mark
phase of a referenced object and should in turn mark all SCM objects
that it references.
--
David Kastrup
___
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: Gets vertical skylines from grob stencils (issue 5626052)
2012/3/7 Janek Warchoł janek.lilyp...@gmail.com On Wed, Mar 7, 2012 at 11:43 AM, Joe Neeman joenee...@gmail.com wrote: 2012/3/6 Janek Warchoł janek.lilyp...@gmail.com Actually, small/zero horizontal padding might give better results in some places, but that needs thorough investigation. Something that, FWIW, never happened with the previous defaults. do you mean that there was no padding previously? No, I mean that the previous default values were never investigated. When the code was written, values were hard-coded with comments like TODO: what's the proper value? Years later, those comments were still there... Cheers, Joe ___ 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: Gets vertical skylines from grob stencils (issue 5626052)
On Wed, Mar 7, 2012 at 10:50 PM, Joe Neeman joenee...@gmail.com wrote: 2012/3/7 Janek Warchoł janek.lilyp...@gmail.com On Wed, Mar 7, 2012 at 11:43 AM, Joe Neeman joenee...@gmail.com wrote: 2012/3/6 Janek Warchoł janek.lilyp...@gmail.com Actually, small/zero horizontal padding might give better results in some places, but that needs thorough investigation. Something that, FWIW, never happened with the previous defaults. do you mean that there was no padding previously? No, I mean that the previous default values were never investigated. When the code was written, values were hard-coded with comments like TODO: what's the proper value? Years later, those comments were still there... ah, ok, i understand now. thanks, 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: 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
Fwd: Patchy email
Boom! All done. -- Forwarded message -- From: pkx1...@gmail.com Date: 8 March 2012 00:29 Subject: Patchy email To: pkx1...@gmail.com Merged staging, now at: 2944a83e59f487894a214769392ce27289accb71 Success: ./autogen.sh --noconfigure Success: ../configure --disable-optimising Success: nice make clean -j7 CPU_COUNT=7 Success: nice make -j7 CPU_COUNT=7 Success: nice make test -j7 CPU_COUNT=7 Success: nice make doc -j7 CPU_COUNT=7 Success: pushed to master --- Next merge in 6 hours. Have a nice day! -- -- James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Please stop pushing to the translation branch until further notice
David Kastrup d...@gnu.org writes: We currently have the situation that bad commits on the translation branch have caused a loss of work in our main repository. While I am trying to sort out the damage, it is not helpful if you keep pushing new material to the translation branch. Please refrain from doing so for now. It makes things even harder to fix. Thanks The situation should now be under control again. The translation branch has been merged with a helper branch that should bring in all the changes from commits that the merge history suggests to be present. Please check that git diff 32b9cd030a1..569714401 (the merge commit resulting in the current translation branch state) is legit and does not lose any of your work. This should bring the translation branch to a state of master located somewhere before 2.15.31. _After_ (!!!) you have made sure that none of your work has been lost here, you can merge from origin into the translation branch, bringing it to a state post 2.15.32. Just to be on the safe side, I would prefer doing the merge of the translation branch back to staging myself next. Once you have checked that the recent fixes have not caused any of your work to get lost and the criss-cross merge has been done, you can continue committing to the translation branch. I apologize for the inconvenience. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Please stop pushing to the translation branch until further notice
Once you have checked that the recent fixes have not caused any of your work to get lost and the criss-cross merge has been done, you can continue committing to the translation branch. I apologize for the inconvenience. Thanks a lot for fixing this. Do you recommend a modification of the current workflow to avoid this problem in the future? It probably doesn't affect me since I don't do branch merges, but just to be sure... Usually I follow your advice sent some time ago to the list: git fetch (to be sure you have the current version of staging) git checkout origin/staging ... commit your simple change ... git push origin HEAD:staging Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Please stop pushing to the translation branch until further notice
Werner LEMBERG w...@gnu.org writes: Once you have checked that the recent fixes have not caused any of your work to get lost and the criss-cross merge has been done, you can continue committing to the translation branch. I apologize for the inconvenience. Thanks a lot for fixing this. Do you recommend a modification of the current workflow to avoid this problem in the future? It probably doesn't affect me since I don't do branch merges, but just to be sure... Usually I follow your advice sent some time ago to the list: git fetch (to be sure you have the current version of staging) git checkout origin/staging ... commit your simple change ... git push origin HEAD:staging It's totally fine. The problem was caused by _not_ adhering to procedures and then digging one self further in instead of resetting and restarting or asking for advice. One problem was rebasing instead of merging between the translation and master branches. That caused some nuisances by ruining the history (changes appearing on more than one branch, consequently at least one revert that I did, \layout-from, had to be redone manually several times). The real problem was that ominous merge (probably with a merge strategy of theirs or ours) that did not actually merge but copy. And the damage that this caused was rather large because it has been a really long time since the translation branch had been merged into staging last before that merge, and since it was a really long time afterwards that the merge into the main line happened. So a lot of history needed fixing. A systematic problem was to check for correctness of the merge by making test and building docs: those won't notice if you accidentally rewind the state of master a few weeks, because we make it a point to have every commit on master pass regression tests and doc builds. If you want to make sure there is not something fishy with a merge, you need to look at the diffs in relation to the parents, at least the diffstat showing which files changed how much. I think the main thing is don't be clever around git. Which I do not heed entirely myself, obviously. But I do hard resets to the state of 15 minutes ago when something does not look good. Restarting from scratch in your local repository is easy with git. Being clever has no place on long-running public branches. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
