On Fri, Mar 16, 2007 at 06:30:46AM CET, Junio C Hamano wrote: > "Shawn O. Pearce" <spearce@xxxxxxxxxxx> writes: > > But other areas die when they get given a bad SHA-1 (for example). > > If the library caller can supply that (possibly bad) SHA-1 to an > > API function, that's just mean to die out. ;-) > > That's a real problem, but on the other hand, perl or whatever > wrapped ones can do the dying (or not dying) before calling into > libgit, so it may not be such a big issue. At least you can catch the die from the library caller using set_*_routine(). ;-) > >> o Documentation (eg, doxygen) > >> o Unit-tests > >> o Add prefix (eg, git_*) to public API functions > > > > Yes. But which functions shall we expose? ;-) > > Before going into that topic, a bigger question is if we are > happy with the current internal API and what the goal of > libification is. If the libification is going to say that "this > is a published API so we are not going to change it", I would > imagine that it would be very hard to accept in the mainline. > Improvements like the earlier sliding mmap() series need to be > able to change the interfaces without backward compatibility > wart. > > In other words, I do not know what idiot ^W ^W who listed the > libification stuff on the SoC "ideas" page, but I think (1) it > is premature to promise stable ABI, and (2) if it does not > promise stable ABI a library is not very useful. I disagree, it can live in the "zero major version" realm and already be very useful for language bindings (say whatever is bundled with git itself) and other nifty stuff. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ Ever try. Ever fail. No matter. // Try again. Fail again. Fail better. -- Samuel Beckett - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html