Junio C Hamano <gitster@xxxxxxxxx> writes: > Thomas Rast <tr@xxxxxxxxxxxxx> writes: > >> Downside: not listing "code merged" as a goal may not make the project >> as shiny, neither for Git nor for the student. > > I'd actually view that as an upside. This sounds like a good first > step for a feasibility study that is really necessary. > > I wonder why the handling of storage corruption and replacement > could be left broken, though. Is that because libgit2 has known > breakages in these areas, or is there some other reason? It's because I don't know enough about what libgit2's state is, and I wanted to keep the scope limited. Naturally, the next step would then be to implement the lacking functionality (if any) in libgit2 so that the test suite passes. I just don't know if that's trivial, or something for the "if we have time" section of the project, or too much work. (I did do a quick "can we reasonably link against libgit2" test where I gave git-cat-file a --libgit2 option that loads blobs with libgit2. There are some name collisions in the git_config* identifiers that need to be resolved, but otherwise it seems entirely possible.) -- Thomas Rast tr@xxxxxxxxxxxxx -- 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