> Not until all the data structures are really really stable. Fine by me to wait, though perhaps not for the same reason, and perhaps not as long.
A libgit.so can deal with data structure changes just as well as a set of command line utilities. So long as everything funnels through one place, you can change by changing that one place. However I am willing to agree that its not libgit time yet, for two reasons: 1) everyone who has two clues on the subject is too busy and too productive on more pressing git issues, and 2) in addition to internal data structures being not yet stable, I suspect that the operations (git commands, options and behaviour) are also not stable. The first step of a good libgit is not coding to the internal data structures, but rather designing the interface (the operations, arguments, data types, and behaviour). So, until people have time, and the interface ops are settled down, its too early to design libgit. Or at least too early to publish a design and seek concensus. If I had the time the first thing I'd be doing right now would be designing libgit on the side, anticipating the day when it was time to publish a draft and engage the community discussion that leads to an adequate concensus. === By the way, a good libgit design, in my view, would isolate the data structures written to files below .git from the data structures presented at the library API, to some extent. Changes in the file structures must be handled without disrupting the library API. If a libgit API didn't isolate the library caller from details of the structures in files below .git, then yes you'd want really really stable data structures, impossibly stable in fact. That way leads to hacks and workarounds in the future, because the data structures are never perfectly stable. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373, 1.925.600.0401 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html