On 1/19/12 10:05 AM, "Graham Percival" <gra...@percival-music.ca> wrote:
>On Thu, Jan 19, 2012 at 03:55:26PM +0000, lilyp...@googlecode.com 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 _______________________________________________ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
