2013/9/30 Alexander Kobel <n...@a-kobel.de> > On 09/30/2013 10:23 AM, Urs Liska wrote: > >> Am 28.09.2013 00:10, schrieb Franciszek Boehlke: >> >>> 2013/9/27 Alexander Kobel <n...@a-kobel.de> >>> >>> I have not real experiance in using git that way, but can imagine a >>> bit how >>> does it work. I think there are two main ways you can go, and possibly >>> using submodules is the third. >>> >>> One way (which i would recommend) is working on one branch, updating >>> tweaks >>> and not bothering with breaking compatibility at all. It will make some >>> scores unusable with the newest version of tweaks, but it is not really a >>> big problem: you can always ask git for the latest commit, which changed >>> score A (), and checkout this particular commit before compiling this >>> score. Drawback: if you want to update score to some intermediate version >>> of tweaks, you have to make it in new branch. However, if you generally >>> update always to the newest version, it is not a problem at all. >>> >> There is another, more severe drawback to this approach. >> Yes, you can always get back to the state when you last touched this >> score. The library will automatically be in the right state and you can >> compile the score. >> But as soon as you want to modify the score again you're stuck at some >> place in your history. You'd have to create a new branch solely for that >> score. >> > > True. And merging will become problematic at some point, too, even if you > always try to stay up-to-date.
Merging? Why can it become problematic, if you would never work on one file in different branches? You should never get any conflict, for merge just type `git merge whatever-branch -m 'piece of cake'` and you are done. Actually, this drawback is present only, if you want to work on scores using older versions of tweaks, without updating them. In other case, you don't need to keep branches for them. And, as i wrote before, don't hesitate before creating new branches, their are cheap, and merging is no problem (unless you have real conflicts). > > > I don't have a ready solution that I have already tested, but I think >> the following approach should work, is sufficiently 'clean' and not too >> complicated: >> You should have (at least) two Git repositories, one for the library and >> one for the projects. >> > > I guess that's the somewhat simplified version of Curt's suggestion to use > git submodules (simplified w.r.t. the learning curve, not necessarily the > overall effort in the long run). > > This is natural because a shared library _is_ conceptually separated >> from the project, that's why it _is_ a library and not simply a project >> file. [...] >> > > Agreed. Agreed. So, if you want to keep library as standalone project, it would be preferrable to keep it in it's own repo. > > Now you can work on the scores as you like and for compiling them >> checkout the right tag in the library repository. (Be sure to always >> have the working tree of the library repo clean.) >> I think this should work without problems. >> Of course you should add a comment specifying the library version to be >> used (and maybe also LilyPond version). >> I could imagine that one could even have a Scheme function that does the >> library checkout for you, but that's clearly over my head. >> > The drawback is, that you have to keep track of versions manually, instead of having it done for you by git. > > I guess I'll stick to a Makefile entry, for simplicity... > > Maybe I should try to guard potentially backwards-incompatible changes and > only define them if some variable is set; in this case, it probably means > that I can live with only the most recent library checked out. Of course, > it'd also be a workaround for being lazy about version control, rather than > a real solution, but it's K(ing)ISS. > If you can afford it without big complications, it is probably best solution. > > > Thanks to all for your input; I'm somewhat tempted to ignore all your > proposed proper solutions, but at least now > - I have an idea of what The Real Thing is, > - I am reasonably confident that I didn't miss an obvious and easy > solution, and > - if I shoot me in my foot, I already know that it was my free choice and > I mustn't complain... > > To cite the Gnus manual: > "You know that Gnus gives you all the opportunity you'd ever want for > shooting yourself in the foot. Some people call it flexibility. Gnus is > also customizable to a great extent, which means that the user has a say on > how Gnus behaves. Other newsreaders might unconditionally shoot you in your > foot, but with Gnus, you have a choice!" > > > Best, > Alexander > > > ______________________________**_________________ > lilypond-user mailing list > lilypond-user@gnu.org > https://lists.gnu.org/mailman/**listinfo/lilypond-user<https://lists.gnu.org/mailman/listinfo/lilypond-user> > Best, Franek
_______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
