> > > ---------- Forwarded message ---------- > From: Kieren MacMillan <[email protected]> > To: David Kastrup <[email protected]> > Cc: Lilypond-User Mailing List <[email protected]> > Bcc: > Date: Sat, 22 Jan 2022 17:34:31 -0500 > Subject: Re: Extracting a "score diff" from two [or more] Lilypond sources > Hi David, > > > What version control system are you using for your score? It will > > probably easiest to look at the source code diffs and do a manual > > summary from those. >
You're probably not going to appreciate this suggestion, because it does not aspire to the auto-magic you desire. However, it is clear to me that the best practice for all software dev is to use commit messages. Commit often, once per thing that you'd like noted in your report, and with a meaningful commit message. Then your commit history is your report. > > The problem is that during various stages of composition / arranging / > engraving / coding: > 1. there can be huge differences in code that represent only a few > small differences in notated output; > This is why you want to use messages to specify the intent of the commit. > 2. there can be very small differences in code that represent > many/large differences in notated output; and > Another reason to use messages to specify the intent of the commit. > 3. there can be many, many small changes in code (cleanup, > variable-izing, moving tweaks to/from the edition-engraver, file splitting, > etc.) that literally have *no* effect on the notated output. > You have the decision to either commit granually, so some commits would not be relevant to your report. Or, this stuff can be included as part of things that are relevant. Which would make this rather like the first case. > > Especially in the third case, combing through all those changes to > manually summarize changes worth noting to others would be time-consuming > and error-prone. If my process were more luxurious, I'd do a "'notable > changes' only" pass, manually summarize the diff(s), and then do the other > code work in a separate pass — the issue is that the timeline of a workshop > doesn't grant me that luxury, so I was hoping there was an automagic way of > figuring out exactly and only those things that needed to be communicated > to the MD/performers in any given score update. > The place to do this is as you work on it, not after. Since these changes are being requested of you, you probably know what the edits are going to be before you start coding, yes? So then, as you go down your list of edits to make, as you fix each one, commit the code with a message referencing the task you just completed. When you are done, your commit history will document the work you accomplished. If, for some reason, you do not know the list of edits you are going to do when you sit down to work, then you just have to do it as you go. When you complete something that is worth reporting, make a commit with a message. Doesn't matter if the entire work is incomplete, since the purpose of partial commits is the message. If you need to distinguish between partial commits and release-able versions, the typical way is to use git tag to identify which ones are stable. And/or adopt a commit message strategy that clearly identifies which ones represent a release. I know this won't help retroactively. But I suspect it should be an easy workflow to adopt since the overhead to making incremental commits is tiny. > > Thanks, > Kieren. > HTH, Elaine Alt 415 . 341 .4954 "*Confusion is highly underrated*" [email protected] Producer ~ Composer ~ Instrumentalist ~ Educator -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >
