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.
