Hi,
* Johannes Schindelin [07-03-16 12:54:52 +0100] wrote:
[...]
Isn't this an awfully long shot?
I'd be happy if the libification project resulted
- in a (static!) libgit.a which can be linked to qgit or similar (being
reentrant, or at least optionally so, and not die()ing all the time),
and
- which does not fix the API yet (at least for the most parts).
We _can_ -- once we agree on a stable API -- expose _some_ functions in a
libgit.so, but that does not have to be the goal for the first step!
First, I think that would be some cleanup "only" since that basically
would mean to
1) make all functions die()ing return some value and handle it and
2) wrap all static vars into structures and pass them around
If you don't choose a design before wrapping things up in structures,
you'll probably end up having one structure per source file (at least
too many structures).
Porting things like qgit to it or writting proper perl/python bindings
is wasted time since you'd have to rewrite all of it once you decided
which functions to expose and which structures to use (calling the
main() routines of builtin's doesn't count as real libifaction, it would
rather be a performance improvement only).
I'd simply try to find a rough consensus on the data structures and the
layer model before starting the project, solve 1), afterwards implement
2) according to it. While 2) happens it would make sense to try to
develop perl, python, C and C++ bindings in parallel to find out early
enough whether the design details chosen are useful for real consumers
outside the git-* tools.
You could put big fat warnings everywhere that parts of the API which
are exposed are heavily unstable and likely subject to change and that
programmers using them will have to frequently start over. Once it turns
out that all the git-tools and all "reference consumers" work it, you
can do some cleanup to get to the final first API version after the
libification project is done.
bye, Rocco
--
:wq!
-
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