As such, other methods, even pen and paper, may well be superior tools for the creative process of composition (although we should also remember the testimony of Bach's sons that the elder Bach always composed away from the keyboard, and regarded the inability to compose without an instrument at hand to be evidence of poverty of invention of course, this does not rule out the possibility that Bach tested out out his draft compositions on a keyboard). But music engraving is the usually the very last step of a compositional or editorial process. LilyPond is incredible for the one purpose it's built for: engraving notated music. Of course millions of cards is not, so the point was kind of moot, but there we were. A language that doesn't require a particular ordering of the cards (=lines) is kind of practical in real world scenarios. Card decks sometimes fell to the ground and got all mixed up. One 80 character line used to be one punch card. When it was conceived it was still usually punched on physical paper cards. This was a deliberate design decision of the language. 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. In reality the files were several gigabytes and for most of them the ordering of the lines was insignificant. Many years ago I worked with a FORTRAN derived file format which from the outset should be ideal for git. XML files are often of that kind, but not only. 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.
From a practical standpoint, text format is necessary but not sufficient for being usefully trackable in git.
This is good to know and technically correct.
0 kommentar(er)
