Bug#515793: ITP: CGIT -- C-code Web Front-end to GIT

[Jonathan Nieder <jrnieder@gmail.com>]

Hi Marc,

Marc Singer wrote:
> On Sun, Jul 29, 2012 at 6:36 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:

>> Did you mean this to be a private reply?
>
> Not really.

Ok, cc-ing the bug.

[...]
> The policy of the git authors is their prerogative.  They've made it very
> clear that they will not support a shared library.  I suppose if you could
> manage the SO as part of the debian packages.  Doing so puts the burden on
> us to track API changes with no promised from upstream.
>
> Is this what you are proposing?

You're presumably thinking of <http://bugs.debian.org/407722>.

No, I agree with Gerrit and think that shipping libgit.a as a library
is a non-starter.  Git's internal APIs (that's what libgit.a is) are
very unstable, and to provide it as a package, even with a constantly
changing name, would be to make an interface promise we couldn't keep.

Instead, I was offering to build cgit from the *same* source package
as git.  I would probably try to upstream the change (putting a
submodule with cgit under contrib/), but even if upstream does not
accept it, we could build cgit in Debian this way.

The main (and only) advantage of this approach is that when an API
break causes cgit to stop working, git would FTBFS.  This immediate
feedback would force the code to keep working together.

Hoping that clarifies,
Jonathan