Thomas Morley <[email protected]> writes: > 2017-09-04 20:01 GMT+02:00 James <[email protected]>: > >> Push: >> >> >> 5179 Let Merge_rests_engraver deal with dotted rests - Thomas Morley >> https://sourceforge.net/p/testlilyissues/issues/5179 >> http://codereview.appspot.com/324310043 >> > > David, as you requested this is splitted into two commits to let you > cherrypick registering for 2.20 > > In my local branch I have: > > $ git log > commit 0b768ff6d2c8f314d7c7d30981fe462cdb5b3b6b > Author: Thomas Morley <[email protected]> > Date: Tue Aug 29 10:44:28 2017 +0200 > > Issue 5179 Let Merge_rests_engraver deal with dotted rests > > Compare simple rests by their duration-length, duration-log does > not take possible dots into account. > Superfluous dots are killed with ly:grob-suicide! > Extend reg-test > > commit 5deb05dde1e821fc4826f4d3256cff1408fde42e > Author: Thomas Morley <[email protected]> > Date: Tue Aug 29 10:24:26 2017 +0200 > > Register Merge_rests_engraver > > Change docs and reg-test accordingly > > > Usually I'd rebase and push with > git push origin HEAD:staging > > Is this the same for a two-commits-patch (I did not have this case before)?
Yes, this should be just the same. It's good etiquette to try to make both commits result in a working LilyPond. I think that is likely the case here. When this is not the case, it's somewhat nicer to commit this as a merge commit from the rebased branch (use --no-ff when merging or the result will be just the same). But I don't think this is the case here, and cherry-picking from inside a branch is a recipe for trouble anyway. -- David Kastrup _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
