From: "Pavel Raiskup" <xraisk00@gmail.com>
To: "Vicent Marti" <vicent@github.com>, "Jeff King" <peff@github.com>
Cc: git@vger.kernel.org
Subject: Re: Histogram diff, libgit2 enhancement, libgit2 => git merge (GSOC)
Date: Tue, 22 Mar 2011 18:32:54 +0100 [thread overview]
Message-ID: <op.vsq9o4mz2m56ex@localhost.localdomain> (raw)
In-Reply-To: <20110320234420.GA1919@sigill.intra.peff.net>
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?
next prev parent reply other threads:[~2011-03-22 17:33 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-20 10:55 Histogram diff, libgit2 enhancement, libgit2 => git merge (GSOC) Pavel Raiskup
2011-03-20 18:06 ` Shawn Pearce
2011-03-22 12:32 ` Pavel Raiskup
2011-03-20 18:25 ` Junio C Hamano
2011-03-20 21:01 ` Vicent Marti
2011-03-20 23:44 ` Jeff King
2011-03-21 0:38 ` Vicent Marti
2011-03-22 17:32 ` Pavel Raiskup [this message]
2011-03-22 18:47 ` Jeff King
2011-03-22 19:18 ` Junio C Hamano
2011-03-21 1:27 ` Jonathan Nieder
2011-03-22 16:43 ` Pavel Raiskup
2011-03-23 0:24 ` Vincent van Ravesteijn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=op.vsq9o4mz2m56ex@localhost.localdomain \
--to=xraisk00@gmail.com \
--cc=git@vger.kernel.org \
--cc=peff@github.com \
--cc=vicent@github.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).