On Sun, 2 Mar 2008, Johannes Schindelin wrote: > On Sat, 1 Mar 2008, Jakub Narebski wrote: > >> BTW. Git has few other such "reimplementing the wheel" things, like >> strbuf, or ALLOC_GROW, or it's own parseopt. I guess main reasons are to >> avoid adding yet another dependency, and that existing solutions doesn't >> fill all git needs. > > Or that the existing wheels are quadratic wheels, and flat. That's what I meant by "existing solutions don't fill all git needs". > Just look at our own parse-options.[ch]. It is _still_ smaller and less > difficult to read than GNU getopt. Yet, it is also much more powerful and > easier to use. I meant here not only 'getopt', but also 'argp' (from libc), or 'popt' library (used by rpm). > Likewise, strbuf compares to Bstring, for example (although you might say > that Bstring is more powerful, but it comes at a price: it clutters the > namespace, and is not as performant as strbuf). I vaguely recall something of discussion about this. > ALLOC_GROW() is so small as to not merit any third-party dependency. True. > Also, I'd like to caution that depending on 3rd-party libraries is not > always easy: just think about how much pain we suffer from the > ever-changing asciidoc package, and the problems wit docbook xsl. I was rather thinking about something like git "dependency" on libXdiff, namely having it embedded in git sources, perhaps as submodule, with git specific improvements / changes / simplifications. I wonder if it would be worthwhile to extract all those useful codelets (mini libraries) like approxidate, strbuf, parseopt, ALLOC_GROW, list utils, etc. into separate micro-projects, to be able to be used by other projects, for *them* not to have to reimplement the wheel. Just a thought... -- Jakub Narebski Poland -- 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
