Hi again!
This sounds probably like the most exciting task for me:
b) Write a minimal Git client using libgit2. Peff keeps bringing this
up and I think it's a bangin' good idea. Write something small and
100% self contained in a C executable that runs everywhere with 0
dependencies -- don't aim for full feature completion, just the basic
stuff to interoperate with a Git repository. Clone, checkout, branch,
commit, push, pull, log. I would totally use that shit on my Windows
boxes. And since it'll be externally compatible with the original Git
client, we can reuse the Git unit tests to test libgit2. HA. Awesome!
Yeah, I would be happy to mentor or co-mentor with Vicent on a project
like that. Not only might it be useful to actually _use_, but my secret
motive is that I'd like to start testing libgit2 using some of the
regular git tests, both for interoperability and for performance.
Do you mean git tests in directory "/t"?
Could you give me a list of possible reusable unit tests? After a quick
overview of test suite in git it looks quite complex to reuse. I haven't
spent a lot of time studying test-suite, but calling:
test_expect_success 'plain' 'command && command && ..'
reinterprets chain of commands given in (2nd) string and in this
commands is often called git as utility with arguments. Even in this
very easy test feature is expected some command-line-interface behavior
from tested utility.. Is this the way how do you want to test this new
libgit2-like tool? So this standalone utility is going to have the
same interface as git has -- kind of substitution of git with "git2"
inside test suite?
This probably will lead to some test suite changes, is it truth?
--
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