Junio C Hamano <gits...@pobox.com> writes:
> Thomas Rast <t...@thomasrast.ch> 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
(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.)
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html