Re: Source management tools for lilypond projects

[James Harkins]

Not sure if this was already discussed (I've been following the thread
somewhat loosely), but it seems to me that git makes it a whole lot
easier to handle a "build token" by virtue of the repositories being
decentralized.

I admit, I'm not an svn expert and it's quite likely there are some
svn workflows I don't know about. As far as I know, a commit in svn
goes straight to the central repository -- mistakes immediately become
public mistakes. When the supercollider source repository switched to
git, it took a while for me to understand how to use branches, merges
and cherry-picks, but once I did, it really seems to me that the git
approach is much better -- because you can correct mistaken commits
before they ever go public.

So, you would do your work in a private branch, and when the new stuff
is ready to go public for other contributors, only then merge into the
master branch (or cherry-pick). If there are conflicts with another
person's work, "git mergetool" to fix them before committing to
master. You still might have screwed something up, but you can "git
reset" to roll back in time, fix things and recommit, all privately
without touching the public repository.

If somebody pushed new stuff to the master branch that you don't have,
git won't let you push publicly: git pull --rebase, which gets the new
stuff and moves your stuff to be last in the revision history. That
may cause conflicts -- "git mergetool" again -- and you have the
chance to retest before pushing.

It's this interim state of "I moved my stuff to master but haven't
pushed it publicly yet" that I think corresponds fairly closely to the
idea of a build token.

Git is really awesome.
hjh