On Thu, Feb 12, 2015 at 08:33:31PM +0000, Craig Dabelstein wrote:
Hi list,
Would anyone be able to briefly share with me how they use Git with
Lilypond; i.e. do you create a separate repository for each
composition you are working on, do you make a separate branch for each
part while you are working on it and then merge when it is finished,
if you sell your music do you pay the fee to have private
repositories, etc.
I'd appreciate any advice you could share.
[...]
I'm only an amateur composer, so take what I say with a grain of salt...
Generally, I have found that it's much better to use a separate Git
repository per composition. Originally, when I first started
transcribing my pieces into LilyPond, I kept everything in a single
repository, but as the pieces grew, the Git history became extremely
unwieldy.
Every time I made a branch for experimenting with some revision of a
particular passage in a particular piece, or for experimenting with
different LilyPond tweaks, it branches *all* of my other pieces as well.
This makes history tracking a pain -- `git log` will show the commits
for all of your pieces interspersed together, making it hard to see what
was going on within a single piece. (Of course, there are ways of
filtering the log, by subdirectory for example, but why put in so much
additional work in the first place?)
It also made tentative work on different compositions bothersome: I make
some tentative changes on composition A, but suddenly an idea occurred
to me about composition B, so I go into B's directory and start making
some changes, and then I decide I want to branch, and then Git complains
that I have uncommitted changes in A's subdirectory that will get
overwritten. So I'm forced to go back to A and commit the changes ... in
a new temporary branch? Bzzzt. Now it complains B has uncommitted
changes that might be discarded (or wrongly committed into A's branch,
so next time I check out the main branch for B those changes aren't
there).
Not to mention the headaches when you want to merge branches that
contain various changes sprinkled throughout your compositions. Not Fun.
In short, it was a royal pain to use a single repository for everything.
I decided that it was much better to keep separate repositories for each
composition. (It took quite some effort -- and lots of arcane Git hacks
-- to transfer the individual histories of each composition into my new
set of repositories -- I have a thing for the history of my
compositions, you see -- but that belongs in another tale. :-P)
Which brings me to the next point: I assume that by paying a fee for a
private repository you're referring to Github or one of the various Git
services out there. This is actually unnecessary -- if you're not going
to be sharing your LilyPond sources with anybody else, you don't *need*
an online Git service to store your repositories. You can just keep them
all on your local PC -- and you can have as many repositories as you
want without any limit, you can even make backup copies of your
repositories if you're paranoid about losing your pieces -- git will
happily create them all for you. This does not preclude sharing PDFs
with your colleagues / musicians; they don't need access to your
LilyPond sources, they just need the printed scores, and you don't need
an online Git service for distributing those.
If you're planning to collaborate with a friend, or a small group of
people, you can also set up a local git server and push/pull from each
other -- you will need a little knowledge in networking to make it work,
but it's generally not that difficult. Git was designed specifically for
this kind of decentralized, distributed workflow.
Centralized online Git services are really more intended for large
collaborative projects where you have a large number of people who must
have access to your files, and who may want to submit changes (pull
requests), submit / track issues, etc.. Unless you are working on a
large collaborative composition, you don't need that kind of service,
IMO.
T