Thomas Rast <tr@xxxxxxxxxxxxx> 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 -- 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