Jeff King <peff@xxxxxxxxxx> writes: > It may also be necessary to use a mixture of git and libgit2 commands to > finish tests. For example, a test which is really about checking "log" > might use "commit", but "commit" hasn't been implemented yet. But it is > still useful information if we cheat and use regular git's "commit", but > test the libgit2 log command. Absolutely, and I don't even think that is "cheating"; it is merely a natural way to work incrementally. > As far as which commands to start with, I would start with plumbing > commands like "update-index", "commit-tree", "update-ref", "rev-list", > etc. Those are basic building blocks that have reasonably simple > interfaces, and they're easy to test. And once you start, I think it > will become more obvious where to go next (because some of the commands > build on the results of others). > >> This probably will lead to some test suite changes, is it truth? Some tests _might_ depend on implementation detail that we would rather not, but I don't think there are too many of them, unless you count the stuff that use "test-<something>" helper binary that link with libgit.a to make direct calls to the internal. I would suggest to consider a failure an uncovered bug in the new implementation by default, and discuss the tests that do depend on the implementation detail of C git on case-by-case basis to be fixed. -- 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