interesting model: homebrew

CSL Development
1

A couple of people on twitter recommended homebrew to me as an
alternative (and quite nice) package manager for OS X, and it got me
thinking that it might have some lessons for the CSL repo idea (and
indeed, potentially for something like zotero translators).

https://github.com/mxcl/homebrew/wiki

Basically, the package descriptions (called “formulas”) are tiny
little ruby applications, and are stored in the main github repo.
These are analogous to csl styles.

There’s a little command line tool that is built in some way on git,
for searching, installing, etc. these packages.

To contribute a new formula, you do as we’ve been imagining: fork, and
then issue a pull request. Then, as it says:

“Now all that remains is to tell a Homebrew collaborator about your
formula so it can be merged.”

E.g. “Homebrew collaborator” = CSL “Style editor”

In some more detail, they also suggest branching, and a few other details:

“We prefer that you create a Pull Request for new and changed brews.
Do not open both an issue and a Pull Request; Pull Requests
automagically create their own issues. One formula to a commit, one
commit to a formula. Keep merge commits out of the request. If you
have any or fixed up commits then please squash your commits. If more
than one file is touched in a commit, and the commit isn’t one logical
bug fix, or the same file is touched in multiple commits then we will
probably ask you to rebase your commits. For this reason you should a
new branch for each pull request rather than using the master branch.
You can delete it after we have pulled your commit.”

Not really sure why they emphasize both forking and branching though,
but I sense it’s important to understand.

Bruce

2

Just an update on this; here’s what happen when I run ‘brew update’
(where you can how it’s relying on git, but doing some additional
work; in this case a human-friendly display of changed files).

$ brew update
remote: Counting objects: 833, done.
remote: Compressing objects: 100% (452/452), done.
remote: Total 731 (delta 522), reused 463 (delta 279)
Receiving objects: 100% (731/731), 91.05 KiB | 53 KiB/s, done.
Resolving deltas: 100% (522/522), completed with 65 local objects.

From GitHub - Homebrew/legacy-homebrew: 💀 The former home of Homebrew/homebrew (deprecated)

  • branch master → FETCH_HEAD
    Updated Homebrew from 64233808 to c1c79d15.
    ==> The following formulae are new:
    c-kermit enca gwyddion mpgtx tcptraceroute
    cdecl exonerate libiptcdata nvi tidyp
    convmv gnu-units libpar2 pstoedit ttf2pt1
    dar groovyserv mac-robber qt-mobility unafold
    dcfldd gtkglext memcacheq redo vde
    ==> The following formulae were updated:
    afflib git-subtree objective-caml
    android-ndk gnu-sed oxygen-icons
    android-sdk google-perftools parallel
    aria2 gradle pbc
    astyle grails pianobar
    avrdude hudson play
    bazaar imagemagick pngcrush
    boost jython portaudio
    c-ares kyoto-cabinet postgresql
    cassandra kyoto-tycoon pv
    ccache leiningen resty
    celt libev riak
    check libevent riak-search
    clustal-w librsvg ruby-enterprise-edition
    cmake libvpx s3cmd
    cmus llvm sbcl
    coffee-script logrotate scalate
    couchdb lxsplit sdcc
    couchdb-lucene lzlib spring-roo
    cryptopp mathomatic stunnel
    dcmtk maven swfmill
    dia memcached synergy
    dialog memcachedb tarsnap
    discount midnight-commander thrift
    drush mongrel2 tomcat
    elasticsearch mpc tor
    exodriver mpd ttytter
    falcon msmtp unison
    figlet mutt valgrind
    findutils ncftp weechat
    gdal ncmpcpp wireshark
    git-flow nmap
    No external commands were updated.
3

…

Not really sure why they emphasize both forking and branching though,
but I sense it’s important to understand.

Still don’t understand the technical reasons, but I stumbled on this
little git ui extension based on a git branching development model.

http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/

In this model, you develop on a branch, and merge to head when you
want to release.

Bruce

4

…

Not really sure why they emphasize both forking and branching though,
but I sense it’s important to understand.

Forking is just making your own copy of the repository. As every git repository is a self contained complete repository (distributed VCS) it’s a bit like if everybody was contributing to the same project using a completely different svn server then merging at key points.

Still don’t understand the technical reasons, but I stumbled on this
little git ui extension based on a git branching development model.

http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/

In this model, you develop on a branch, and merge to head when you
want to release.

One of the projects I work on, we actually merge to a ‘develop’ branch then create tags of releases on this develop branch. The master branch is pretty much untouched. Branching and merging without the hassle associated with it (e.g. in subversion) makes life much easier, especially when reviewing previous work. There is a bit of an overhead to learning it, and to dealing with some of the mechanics from time to time, but this is offest by other advantages.

5

Yes I know that; particularly so with mercurial. But git has in-repo
branches as well, and in this case, the project suggests
simultaneously forking the repo and doing the changes on a branch
within that fork. It seems like effectively double-branching (and so
redundant), but assume there must be a reason for it.

Bruce

6

OK, It’s because each commit is actually content addressable - the SHA1 hash (commit ID) is associated with the actual content of the commit (although as with other hashes of the same type, it’s one way, so you know the content is the same for commits with an identical SHA1 commit ID, but you don’t know what the content actually is it is without looking at it). As I understand it branches are just labels which organise groups of commits within a particular repo - these can be on the local repository, on a remote repository, or on the local repo but set up to track a remote branch (to facilitate multiple people working on the same branch without having to be online continuously).

I think the best summary of working with remote tracking branches I’ve seen is here: http://djwonk.com/blog/2009/04/18/tracking-remote-git-branches/

7

Thinking about this again …

A couple of people on twitter recommended homebrew to me as an
alternative (and quite nice) package manager for OS X, and it got me
thinking that it might have some lessons for the CSL repo idea (and
indeed, potentially for something like zotero translators).

https://github.com/mxcl/homebrew/wiki

Basically, the package descriptions (called “formulas”) are tiny
little ruby applications, and are stored in the main github repo.
These are analogous to csl styles.

There’s a little command line tool that is built in some way on git,
for searching, installing, etc. these packages.

So this is in part a wrapper around git. So if you do:

$ brew update

… it’ll run a ‘git pull’ and then report as follows:

Updated Homebrew from 9cc83bc4 to c119a67c.
==> The following formulae are new:
dsh gqlplus libdshconfig memcache-php
easy-tag hiredis libtrace mu
geomview jslint4java maven-shell x3270
==> The following formulae were updated:
android-sdk gst-plugins-base mod_python

It strikes me a little script (using either either node.js or ruby?)
along these lines could be useful, with possible CSL-specific commands
like:

$ cslrepo preview apa.csl

… which could run a previewed diff on a changeset of a style before
committing the change.

It could even be extended to do the minimal new style wizard I’ve
previously mentioned:

$ cslrepo new
Field:

  1. humanities
  2. law
  3. sciences
  4. social sciences

etc.

Bruce