Re: [darcs-devel] Darcs-Git: upgrading to Git 0.99

From: David Roundy <droundy@abridgegame.org>
Date: Jul 17, 2005, 10:40 UTC
Message-ID: <20050717104035.GA8315@abridgegame.org>
In-Reply-To: <7islyev5s4.fsf@lanthane.pps.jussieu.fr>

On Sat, Jul 16, 2005 at 10:45:47PM +0200, Juliusz Chroboczek wrote:

> 
> I'd like to upgrade the Git code used in Darcs to 0.99 (we're
> currently using 0.6). [...]

Great!

Show 18 quoted lines

> Now I'm wondering how to do that.  Currently, I'm using a nasty hack
> using the C preprocessor to include just the sources we need in
> Darcs.  As 0.99 builds a ``libgit.a'', I'd like to use that instead.
> 
> There are three ways to do that:
> 
>   (1) require that the users put a suitable libgit.a in /usr/local/lib
>       before building Darcs, and distribute a tarball of Git from
>       darcs.net;
> 
>   (2) include just the sources needed for libgit.a in Darcs, and have
>       the Darcs build build a local libgit
> 
>   (3) as (2), but include all of Git, including their
>       ``user-friendly'' scripts.
> 
> Solution (2) will include 33 files totalling 167KB, while (3) is about
> a megabyte of source.

I'd really prefer option (1), *if* the git folks can confirm that the API is at least intended to be stable. As an subtly different option, we could include a script that would download and untar the git sources and then build them. But it'd be great to allow users to upgrade their libgit without our intervention if a protocol or repository format change occurs that doesn't affect the API.

I guess the real question is whether the API is more or less stable than the protocols and disk formats. If the API is more stable, we'd rather link with an external libgit and be robust with respect to on-disk format changes (such as pack files). If the on-disk format is more stable, we'd rather include a copy of the source code and be robust with respect to API changes of libgit.

A fourth option would be to include git sources, but also include a configure flag that could be used to link with an external libgit. This is probably the most robust solution, but also the most complex solution (and thus probably not the best).

-- 
David Roundy
http://www.darcs.net