I had said: "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."
Actually, I think I was wrong about that. At first I thought I was doing something completely different than normal Git practice, now it looks like it may be more of a tweak.
The end-programmer can use tags to list out the hacks being used (the prerequisite hacks), and so it doesn't matter how many commits there are between tags. If you tag your library "yourname.lib-foo-v1", then have a whole bunch of development history, and then tag the next release as "yourname.lib-foo-v2", that works fine. Which is standard Git practice.
The important thing is that once you've publicly published a hack with some ancestor commit, that you always include that ancestor commit. For example, it won't work to say, "hmm, for v3, I don't need all that old development history that I published with v2, so I'll publish a clean patch series that has commits only for the changes between v1 and v2, and between v2 and v3". That will break the merge when the end-programmer tries to merge your v3 on top of the v2 copy they have.
It is OK to privately develop a library, see that you have a messy development history, and then decide you want to publicly publish a commit that has only the differences from your previously publicly published version. The trick is whatever commits you've made public in the past, you keep as ancestor commits as you move forward.
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).
I added a section about how to include a previous commit as a parent of your commit without including any of the previous commit's code.
An example of when you'd need to do this is when you're publishing a fix which replaces some previous fix and doesn't use any of its code, and you want Git to use your fix instead of the previous one.
Branches are useful for developing libraries and for following along library development. It was a pain trying to pull in different libraries from different repositories by referencing them by branch name, at least the way I was doing it.
