Whenever working on a notation project of some extent you will run into the situation of having printouts of intermediate states of the score, for example to do proof-reading. And as soon as there are more than one of these printouts you will have to take care tagging them appropriately in order to know which state of development they represent. As I’ve written over and over in this place version control can become an indispensable tool for not getting lost in project development. So why not just integrate the two approaches and print version control information directly on the score?
We’ve been discussing this idea on several levels for quite some time. For example it would be nice to be able to integrate Git information in the metadata of the PDF files or in the resulting file name. And it would be nice to have tools in editors like Frescobaldi to handle versioned scores and offer graphical approaches to comparing them. Well, all this hasn’t been achieved or even thought through to the end, but thanks to a comment to an earlier post of me by Lars Haulin I was now able to implement a way to print relevant information with LilyPond directly, for example in the tagline.
I have added a snippet to our openLilyLib snippets repository which can be found in the
editorial-tools/git-commands directory. Currently it provides a number of markup commands printing
the short version of the Git committish
the oneline commit message of the latest commit
the date of the last commit
info about the author of the last commit
- the committish and oneline message of the parent commit
the branch we’re currently on
the number of commits that lead to the current commit
An additional Scheme function
gitIsClean determines if there are changes to the repository on top of the latest commit. Of course this is important information because often one would rather create a commit after doing the printout – and in that case the reference to the latest commit doesn’t really tell the truth about the state of the score. As I didn’t want to prescribe how such information is presented this function simply returns a boolean value and the user has to provide a markup on her own.
In addition there are more “verbose” commands that return multiline text, currently
\gitDiff. These can also provide interesting state information but should usually be printed on separate pages or even a dedicated bookpart, otherwise they would severely disturb the score layout.
As the snippet provides the generic markup command
\gitCommand it is quite easy to add custom command for your specific needs.
Have a look at the attached example document to get a better idea of what is possible.
Or download the two files definitions.ily and example.ly, save it beside one another within a Git repository and compile the
As usual, any suggestions are welcome.