Re: Git/Lilypond workflow

[Steve Lacy]

Hi,

I'm a software engineer by trade and have been using git for software development for quite some time.  

Let me first start saying that there are *many* different possible workflows, and each user needs to come up with their own workflow that they're comfortable with. 

With respect to branching, the most important thing to remember is that your *local* branches need to be ever pushed to the "origin" repository.  Or, to put this in layman's terms:  You can create many branches locally, work through all your possible changes and experiments, and then when you have something that you like, "squash" (which is a "git rebase") all that work into a single commit that you push that to your origin repository.   This technique avoids the issues that H.S. Teoh was talking about having a polluted git history. 

In software, we generally avoid multiple repositories, and stick to "one giant repository" and use branching and tagging for releases and milestones.  

For LilyPond development, I would think that there are some imortant questions to ask first. 

- Is there any shared code at all between different scores?  I can imagine that you may have some utility functions, layout helpers, etc. that you share across many scores.  If you share code like this, then one repository will be easier. 

- Are you collaborating, and how?  How well versed in git are your collaborators?  

Again, it software, the flow most people use are: 

- Make many local branches that no one else ever sees. "git commit" to these branches very frequently. 

- When you have something that "looks good" in a local branch, rebase it into a single commit using "git rebase -i" 

- Allow collaborators to view this rebase'd "final version" of your work.  This could be by pushing to a "dev branch", or by sending a diff via e-mail.  Your choice. 

- After review is complete, either "merge dev branch into HEAD" or "apply patch that was the result of new work" (per step(s) above) 

There are lots of good websites outlining possible workflows, and it'll take some time and experimentation to get things right.  Take a look at:

https://www.atlassian.com/git/tutorials/comparing-workflows

and 

https://about.gitlab.com/2014/09/29/gitlab-flow/

I also agree 100% with H.S. Teoh when it comes to "private repository" versus "self-hosted repository" 

If you want something cheap & easy, just put your "private" git repositories on dropbox.  That way, you can collaborate with others by sharing the dropbox folder (read only or read/write as you see fit).    There's no need to use a private github repository unless you really want to collaborate with lots of people, or you want to invite collaborators that you don't know personally (i.e. the forking flow that requires a code review to publish)

Good luck and I'm happy to answer more git questions if you ever have some. :) 

Steve

On Thu, Feb 12, 2015 at 1:00 PM, H. S. Teoh <address@hidden> wrote:

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

--
Try to keep an open mind, but not so open your brain falls out. -- theboz

_______________________________________________
lilypond-user mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/lilypond-user