David,
On 28/12/2018 14:13, David Kastrup wrote:
Thomas Morley <[email protected]> writes:
Hi all,
I think we need some guidelines in the case a new lsr-snippet is used
for the docs.
See https://sourceforge.net/p/testlilyissues/issues/5251/
James askes not to run makelsr, because a plethora of changes will
clutter the patch-set.
OTOH, a patch can't stand alone and can't be applied for testings by
reviewers without makelsr. So I voted for doing makelsr.
The CG is not clear in this regard (or I didn't understand it)
So how to deal with it?
The best way to do that in my opinion is to do both. Have the makelsr
changeset as a separate commit (and review changeset) but commit as a
single merge commit, by merging a branch that contains the intermediate
commits that would not compile on their own.
For my ignorance, what happens if one wanted to cherry pick the the
'single merge commit' - wouldn't it be better to have two separate commits?
I always have done this in the past - added the snippet-included-patch
as one commit and then run makelsr and commit that as a second.
e.g.
http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commit;h=7b3b9d18392ceeb9b3dc88eb0c18ccaac7e71281
regards
James
_______________________________________________
lilypond-devel mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
