Re: linking libgit.a in C++ projects

[Dmitry Potapov <dpotapov@gmail.com>]

On Thu, Jul 31, 2008 at 01:14:46PM +0200, Petr Baudis wrote:
> 
> I don't think this is that big a problem; there are applications that
> are doing this already, e.g. cgit, and if you tie your application to
> a particular git version by for example making git a submodule of your
> source, this is pretty safe; it will just mean that you will have to
> do some non-trivial porting of your code to the new interface each time
> you update - but I think large changes in the interface are pretty rare
> in practice by now, and there shouldn't be much on the horizon either(?).

What you see as large changes depend on how well you know git internals.
Git develops very quickly and if someone who is trying to use libgit.a
does not follow git development closely, it may happen pretty soon that
even not so big changes will become a huge problem to accomadate them.
As result, the program may stick with an old Git version, and that puts
users of this program in the situation where they cannot use their
favorite frontend with new repositories.

> What would be the reason to disallow C++ users? The costs aren't that
> high, and (modulo, say, extern "C" { }) there should be no C-C++
> compatibility issues, right?

I mean that putting  extern "C" { } around should be sufficient to use
this library in C++. But I see now some current headers contains some
C++ keywords and that causes the problem. So, yes, those headers should
be corrected if they become part of external available API. I am not
sure whether it makes sense to correct them now, but there are only
three places where C++ keywords are used:

diff.h:135:extern int diff_tree_sha1(const unsigned char *old, const
diff.h:137:extern int diff_root_tree_sha1(const unsigned char *new,
object.h:38:extern const char *typename(unsigned int type);

So, the patch should not be large, and it is up to Junio to decide
what to do about it.

Dmitry