On 26-3-2011 0:12, Motiejus JakÅtys wrote:
Hello, I wrote similar letter before, but did not receive feedback I was expecting.
I wrote a mail on the same topic to the libgit2@xxxxxxxxxxxxx mailinglist, because I got interested in the same project (although I will not be a GSoC student).
http://librelist.com/browser/libgit2/
According to Jeff King[2], I should start with plumbing commands. I agree. However, how deep? I.e. do I have to make sure all git rev-list possible arguments are implemented?
I guess a lot can be copied from Git itself. Actually builtin/rev-list.c consists mostly of command line arguments parsing methods, and outputting functions. The key is to parse what you want to know and ask libgit2 to provide the info. If libgit2 has implemented the basic functionality that is needed, the rest would be relatively simple.
Are we aiming for a distributed 100s of executables architecture (current git), or single huge binary? I would go for single executable for to higher portability. Is that ok?
AFAICS, current git is a single binary on Windows already.
Build tool. Currently libgit2 uses waf. I am not against it (I've chosen waf for one of my own C++ projects), However, it's too clumsy for me. Is it me who lacks experience? Scons looks much easier for me. Moreover, we do not need automatic configuration, so it makes waf "overfeatured".
Why not CMake which is also used for libgit2 ? I already wrote a CMakeLists file for your git2 app.
I am a student and would like to do this take this up in GSOC. I just received a letter from Vicent Marti with sort of confirmation that the project is interesting for the community.
As you know, this project can be possibly fulfilled by a GSoC student (either you or someone else). Maybe people are awaiting this before diving into the project.
Vincent -- 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