Re: Git GSoC 2014

[David Kastrup <dak@gnu.org>]

Thomas Rast <tr@thomasrast.ch> writes:

> Here's my moonshot:
>
> --- 8< ---
> Replace object loading/writing layer by libgit2
>
> Git reads objects from storage (loose and packed) through functions in
> sha1_file.c.  Most commands only require very simple, opaque read and
> write access to the object storage.  As a weatherballoon, show that it
> is feasible to use libgit2 git_odb_* routines for these simple callers.
>
> Aim for passing the git test suite using git_odb_* object storage
> access, except for tests that verify behavior in the face of storage
> corruption, replacement objects, alternate storage locations, and
> similar quirks.  Of course it is even better if you pass the test suite
> without exception.

[...]

> That absolutely requires a co-mentor from the libgit2 side to do,
> however.  Perhaps you could talk someone into it? ;-)
>
> Motivation: I believe that migrating to libgit2 is the better approach,
> medium term, than rewriting everything ourselves to be nice, clean and
> thread-safe.  I took a shot a while ago at making the pack reading code
> thread-safe, but it's adding mess when we could simply replace it all by
> the already thread-safe libgit2 calls.  It also helps shake out
> incompatibilities in libgit2.

That would either require forking libgit2 for Git use or stop dead any
contributions to that rather central part of the git codebase from
contributors not wanting their contributions to get reused in binary
proprietary software.

It would also mean that no serious forward-going work (like developing
new packing formats or network protocols) can be done on a pure GPLv2
codebase any more.  So anybody insisting on contributing work under the
current Git license only would be locked out from working on significant
parts of Git and could no longer propose changes in central parts.

Now this can all be repealed by the "developing the atomic bomb does not
mean that one has to use it" argument but even if one does not use it,
the world with and without it are different worlds and occupy mindshare
and suggest "solutions" and "diplomacy" involving it.

So this is definitely a large step towards a situation where erosion of
the existing license and related parts of the community becomes more
attractive.

There is the rationale "we can always say "no" at the end".  How do you
explain this "no" to the student who invested significant amounts of
work into this, in a project proposed by the Git developers?

This definitely should not be "we'll think about it if and when that
project is finished" material.

-- 
David Kastrup