On Fri, 16 Mar 2007, Steve Frécinaux wrote: > Also, I guess what people would expect from a C library is roughly the > same as for the current plumbing... just easier to use from another > program. It doesn't need a low-level access to data structure (most > applications would be to interact with an existing repo or to store data > for a third-party software, something that is high-level) and I don't > think such an opaque API would be a huge constraint as soon as you keep > the Object/Index/Tree/Commit/etc basic opaque structs. Right. I like that idea. A good way to define the lib API needs then might be expressed as follows: Each existing plumbing commands must be turned into the minimal implementation required to interact with the libgit public API and display results. In other words, the public libgit API should provide the same functionality as existing plumbing commands such that those existing commands will only need the necessary code to bridge the C interface with the existing command line interface. Then, of course, there is the matter of reentrancy. But that's still a minor API detail even if it is not a trivial issue implementation wise. But the API must be right as this is what we'll be stuck with even if the implementation may change. And as far as an API definition is needed I think that it should reflect the current plumbing which is actually the real API that grew naturally and has been proven useful. Nicolas