[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
Re: Git/Lilypond workflow, Noeck, 2015/02/12
Re: Git/Lilypond workflow, Wilbert Berendsen, 2015/02/12
Re: Git/Lilypond workflow, RomanticStrings, 2015/02/15