Re: Issue 2228 in lilypond: Some users prefer to minimize partial beams rather than beam by the beat

[Carl Sorensen]

On 1/19/12 10:05 AM, "Graham Percival" <address@hidden> wrote:

>On Thu, Jan 19, 2012 at 03:55:26PM +0000, address@hidden wrote:
>> New patch set after:
>> 
>> scripts/auxiliar/makeslr.py
>> git add Documentation/snippets/new/strict-beat-beaming.ly
>> git commit Documentation/snippets/new/strict-beat-beaming.ly
>> git reset --hard HEAD
>> 
>> This properly updated strict-beat-beaming.ly, but avoids showing all
>> of the other snippets changed by convert-ly.  Maybe we should add
>> this to the CG.
>
>The proper thing is to:
>- make a branch
>- do a local lsr update
>- make your code and doc change
>- do a local lsr update
>- review, then merge with staging as a single commit or a special
>  "merge commit" which git-rebase will handly properly; consult
>  David about what that means in exact git terms.
>
>I personally would just squash the branch into a single commit,
>but a "separate branch merge" would be more appropriate for larger
>changes.

Why is this the proper thing to do?

The objective is to get the new snippet into the tree.  The way to get the
new snippet into the tree is to add it to D/s/n and do a makelsr.py.  But
this also updates a bunch of other files.  Why is not preferable to throw
away all the rest of the changes, which will be redone as part of a
release?

Unless we are going to expect *every* user to do a local makelsr.py for
*every* branch they create, it seems unreasonable to ask them to do it in
advance for some branches.

I'm positive that the commits obtained will be exactly the same.  In fact,
I'll go ahead and demonstrate it.

Thanks,

Carl