Am Sa., 29. Dez. 2018 um 18:40 Uhr schrieb Phil Holmes <[email protected]>: > > ----- Original Message ----- > From: "Malte Meyn" <[email protected]> > To: <[email protected]> > Sent: Saturday, December 29, 2018 9:29 AM > Subject: Re: makelsr > > > > > > > > Am 28.12.18 um 21:33 schrieb Phil Holmes: > >> A little late to the party, but I am almost certain that running makelsr > >> to create an LSR patch and then (after testing with at least make, make > >> doc) and pushing that patch, and then putting up the doc patch for review > >> is a perfectly accestable way to go. I've rather got out of the habit, > >> but I regularly used to run makelsr, eyeball it carefully (as in the CG) > >> then push it without review. Extra files in the patch won't break the > >> build, only missing ones. > > > > I think that this sounds like the easiest way. That way every single > > commit ‘make’s without problems, there is no makelsr output in the review > > of the then following doc patch and one doesn’t have to mess with > > different branches. (Ok, I have to admit that I simply didn’t understand > > exactly how the solution with separate commits and a merge should look > > like. But it seems as if I’m not the only one.) > > > > Could you, Phil, please push such a makelsr run as you described? As long > > as I don’t have permission/trust from some of you to do this without > > review, I’d have to go the ‘long’ Rietveld way. > > > > Of course, if there are objections against this way, I’ll try to figure > > out how exactly the ‘separate-branches-and-merge-commit’ thing works. > > Pushed to staging and then patchy-ed to master. > > -- > Phil Holmes
Hi Phil, I did my own experiments with makelsr locally, because I wanted to become more familiar with it. In my local testings I stumbled across some possible issues. They are visible in your patch as well http://git.savannah.gnu.org/cgit/lilypond.git/commit/?id=00f0ca84dbb015617f8ce36dd13db59bbfef8f11 (1) Why is always \version "2.20.0" inserted? Doing convert-ly manually will make for "2.21.0" (2) Looking at this diff: diff --git a/Documentation/snippets/two--partcombine-pairs-on-one-staff.ly b/Documentation/snippets/two--partcombine-pairs-on-one-staff.ly index c1a36ec..900167f 100644 --- a/Documentation/snippets/two--partcombine-pairs-on-one-staff.ly +++ b/Documentation/snippets/two--partcombine-pairs-on-one-staff.ly @@ -48,7 +48,7 @@ fis b,2 @} } } -partCombineUp = +partcombineUp = #(define-music-function (partOne partTwo) (ly:music? ly:music?) "Take the music in @var{partOne} and @var{partTwo} and return @@ -66,7 +66,7 @@ in the output to use upward stems." >> #}) -partCombineDown = # +partcombineDown = # (define-music-function (partOne partTwo) (ly:music? ly:music?) "Take the music in @var{partOne} and @var{partTwo} and return Why is the user generated variable partCombineUp/Down changed to a lower-case "c"? Is the convert-rule insufficient? (3) Looking at this diff: diff --git a/Documentation/snippets/markup-lines.ly b/Documentation/snippets/markup-list.ly index 6ff040e..3015055 100644 --- a/Documentation/snippets/markup-lines.ly +++ b/Documentation/snippets/markup-list.ly @@ -10,11 +10,11 @@ lsrtags = "text" texidoc = " -Text that can spread over pages is entered with the -@code{\\markuplines} command. +Text that can spread over pages is entered with the @code{\\markuplist} +command. " - doctitle = "Markup lines" + doctitle = "Markup list" } % begin verbatim %% updated/modified by P.P.Schneider on Feb. 2014 This a renamed snippet. But anyway, I can't find any snippet in git which uses \markuplines. Where does it come from? Cheers, Harm _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
