Re: PATCHES - Countdown for September 4th

[David Kastrup]

Thomas Morley <address@hidden> writes:

> 2017-09-04 20:01 GMT+02:00 James <address@hidden>:
>
>> 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 <address@hidden>
> 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 <address@hidden>
> 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