lilypond-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Git + LilyPond


From: Peter Bjuhr
Subject: Re: Git + LilyPond
Date: Sun, 07 Jun 2015 11:35:46 +0200
User-agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0

Thanks for all suggestions. It's really appreciated!

I have a question for those who use version control (and especially Git) with LilyPond:

When I write a new piece (or rather when a first version is written) I'd like to edit this as a single repo. But when it's (more) finished I think it would be better to collect it with other pieces in a larger repo (with the history intact of course). How can I do this? Is it a good idea?

why not using branches?

if you're intending to merge repositories later anyway it might make sense to have them in one repository right from the start.


I haven't really considered this because I like the idea of having the pieces initially as single repos and only use the larger repo as a showcase/collection/library. But I shall give it some more thought though!

All the revision control magic I've seen until now ended with "How could we ever have
thought that was a good idea". Go with the flow.

I agree! With Git I think it is often best to keep it simple - code orderly, record the the history and keep it in sync. (It's no bad bad thing to know some Git magic though if you really need it...)

Therefore I was also hesitant of following some more advanced strategies I found.

See e.g.
http://blog.karssen.org/2013/06/06/importing-a-git-repo-into-another-one-keeping-all-history/
and several other discussions on the internets.

This approach isn't very good because it includes an artificial commit that moves all stuff to some directory.

You should rather use a subtree merge: https://git-scm.com/book/en/v1/Git-Tools-Subtree-Merging which allows to port commits between "big" repo and any remaining "subrepos"

This is very useful. I'll save this for later reference. But I'm not sure I need this technique for the present purpose.

What I now consider is my best option in this case is to simply add the single repo as a remote in the larger repo and merge it in.

I'm glad I asked the question. I were complicating things too much before, I think.

Best
Peter



reply via email to

[Prev in Thread] Current Thread [Next in Thread]