lilypond-user
[Top][All Lists]
Advanced

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

Re: Git/Lilypond workflow


From: H. S. Teoh
Subject: Re: Git/Lilypond workflow
Date: Thu, 12 Feb 2015 13:44:43 -0800
User-agent: Mutt/1.5.23 (2014-03-12)

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



reply via email to

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