[tunesmith]

I love lilypond as a programmer because I can use git. I have a private git repo that has lead sheets for all my favorite jazz standards (with my own reharms), notation at various levels for my originals, arrangements of songs for my a cappella friends, and a cue for a full film score project I did. The output quality is amazing, but the best part is I don't have to worry about forward/backward compatibility. None of my old Sibelius scores are openable anymore without spending hundreds on an upgrade, but all my lilypond scores will always be available to me.

[sudobash1]

I use it for the same reason, but also it is worlds ahead of Musescore if you want to put together a songbook (particularly if you also have tex experience). The best advice Musescore has for making a songbook with many scores is to use a PDF editor on the output.

Also as a programmer, Lilypond is programmable, and nearly infinitely customizable (similar to tex). I love that I can write some style information in a "header" and include it in every score. In my current project I am writing a lot of SATB choral songs in book format. But I also want to do a melody only edition. Just tweaking a header file, I can hide all the other voices, no problem.

(I also use Musescore, which I prefer for composition or simple projects. But when I want to output a large finished product, I always go back to Lilypond.)

[em3rgent0rdr]

For the record, uncompressed MuseScore files ".mscx" are simply XML, and thus can be tracked in git if so desired.

[weinzierl]

This is good to know and technically correct. From a practical standpoint, text format is necessary but not sufficient for being usefully trackable in git. If you cannot efficiently diff and merge a format having the file in git gains you as little as having a binary file in git.

XML files are often of that kind, but not only. Many years ago I worked with a FORTRAN derived file format which from the outset should be ideal for git. In reality the files were several gigabytes and for most of them the ordering of the lines was insignificant[1]. Not only is git not particularly good with very large files (it certainly wasn't back then), diffing and merging files where several hundreds of millions of lines jump around arbitrarily is practically impossible.

[1] This was a deliberate design decision of the language. When it was conceived it was still usually punched on physical paper cards. One 80 character line used to be one punch card. Card decks sometimes fell to the ground and got all mixed up. A language that doesn't require a particular ordering of the cards (=lines) is kind of practical in real world scenarios. Of course millions of cards is not, so the point was kind of moot, but there we were.

[oDot]

I've created FileMonger exactly for that usecase. If score diffing is useful for people please send me an email at anything at https://FileMonger.app