I've been writing up a little something along similar lines. I hadn't thought using a commit-per-hack approach - it runs completely counter to the way I think about version control (which can briefly be summarized as "commit early, commit often"), so mostly what I'm writing is a howto on using `git-rebase` to handle development sanely (and an associated rant on why we should really just use darcs; if you haven't already tried darcs, I highly recommend it). I think in the long run, even for Arc, representing libraries directly in version control may get hairy. Git is not very good at dealing with subtly different histories, though I suppose restricting ourselves to one commit per patch/library/hack may help this somewhat. Ultimately it seems like a good idea, I'm just not sure present version control systems, even git and darcs, are up to the task.
Right, I'm using Git as a way to pull in and manage hack dependencies, instead of for version control.
You can first use Git to develop a library using Git as a version control system and then publish your library using Git in my approach. However you can't use the same commit for both: you can't take a commit that has version control type ancestors and publish it as a dependency type commit. Instead you have to create a new commit which has only prerequisite hacks as ancestors.
This is somewhat similar to creating a clean patch series: you don't lose your development history, but you don't expose the upstream recipients of your clean patches to the messy details of your development history either.
Thanks for the comment, I'll add a paragraph talking about this.
I don't know yet if Git is up to what I want it to do either, but it seems to be OK so far, if a bit awkward. (Which isn't surprising, since after all it was designed as a version control system).
