On Thu, Feb 12, 2015 at 01:29:55PM -0800, Tim Walters wrote: > My approach is almost the opposite. I have everything in one > repository, with each composition in its own folder, because: > > --I have files that are common to all compositions. Having separate > copies of these all over the place is exactly what I don't want. If I > change, for example, the script that renders to PDF/MIDI/audio, I want > all past and future compositions to use that script.
If it were me, I'd use a dedicated repository for the common stuff, put it in a specific location, and just point the scripts in each composition's directory at it. > --"git log <folder>" is just as easy as "git log". True. > --Creating new compositions is much easier. It's not *that* much easier than `mkdir new_composition; cd new_composition; git init`. :-) The nice thing about git is that even creating repositories is cheap and fast -- you don't need to setup a whole new server for it, etc., just create it on the spot. Don't like it? Just delete the whole directory, and you're done. Want a backup copy? Just `git clone ...`. Don't need the backup anymore? Nuke the directory. (In fact, this is how I initially split my single repository into multiple ones: `git clone` the original repo, then `git-filter-branch --filter=subdirectory` to discard everything except a single subdirectory, then repeat with the next subdirectory, etc.. The original repo is left intact in case I screw up and need to go back to the original state of things. In any other version control system (that I know of, anyway), doing this would be an extremely time-consuming and arcane task.) > I rarely branch, but if I did, I wouldn't be at all hesitant to commit > tentative changes on a branch in order to work on another branch. > That's the standard git workflow, and really the whole reason for > branching in the first place. If you change your mind, just revert. If this workflow works for you, sure. What I didn't like about it was that while working on composition A, I may be in branch B1, but then I get an idea for composition C, and when I go into C's subdirectory, it's still stuck at the old state when B1 first branched, rather than the latest state. I have to checkout C's latest branch first -- and if I forget, I have to commit/rebase/squash/etc.. It's certainly *possible* to work this way, it's just not as nice IMO. > I run my own git server on the same Linode (<https://www.linode.com>) > where I host my band's website. A local git server is not bad, but > doesn't give you off-site backup. It's also occasionally handy to be > able to work on a remote machine. True. OTOH you *could* setup a backup PC on a LAN, and just push your changes there every now and then. Well, whatever works for you. :-) Speaking of remote servers (Linode, etc.), you don't even need to run a dedicated git server; if you have ssh access to the server, that's good enough for pushing/pulling with git, just use ssh://... in your git remote URL. T -- One Word to write them all, One Access to find them, One Excel to count them all, And thus to Windows bind them. -- Mike Champion _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
