Re: GSoC questions

From: Jeff King <peff@github.com>
Date: Mar 31, 2011, 19:27 UTC
Message-ID: <20110331192758.GD16981@sigill.intra.peff.net>
In-Reply-To: <AANLkTi=TOYOj2HWzy62G24Kg=NZC5X1=psA3GDhaH3Hc@mail.gmail.com>

On Thu, Mar 31, 2011 at 01:58:23PM +0200, Vincent van Ravesteijn wrote:

Show 17 quoted lines

> On Thu, Mar 31, 2011 at 11:36 AM, Alexandru Sutii <sutii.alex@gmail.com> wrote:
> > I have also used the original "usage.c" and "git-compat-util.h" for
> > error handling.
> > Is there a problem if the git2 client will reuse non-gitcore code, such
> > as string parsing code, parameter parsing code, etc?
> 
> I guess the git2 client will consist solely of non-gitcore code, as
> all the gitcore code will be part of libgit2 eventually.
> 
> I expect the transition to be not so difficult for many commands, but
> the challenge I see is to do it not by 'reusing' git code, but by
> 'sharing' the code. Otherwise we end up with a second Git and someone
> should spend a lifetime to keep the reused code in synchronisation
> with the git repo.
> 
> This might, however, require some (major) refactorization to the Git
> code. I don't know whether that will be supported by everyone.

I had sort of assumed that git-core code would be taken as inspiration, but that it would be an entirely new implementation, based around the error handling and build infrastructure provided by libgit2.

And obviously libgit2 isn't going to provide everything you need. For example, in the mktag implementation that Alex posted, there's still a big verify_and_create_tag() function. I would prefer to see that code broken into library-sized chunks and added to libgit2 itself, with the eventual goal that mktag.c could consist of a very short main() function that just parses options calls into the library (and yeah, I realize that things are not always so simple, but it is a goal to work towards).

So when starting with a command, rather than trying to port code from git.git, look at what it does and say "how would I do this in libgit2? What else needs to be implemented in the library before I can do it?". And then write the bulk of your code for libgit2, filling in those gaps in functionality, and as a final step make the actual executable command.

In this case, one of the things that is lacking is the die() error handling. In general, that is not something libgit2 wants, because its goal is to pass errors back up the call chain. Another thing that is missing is option-parsing (though mktag doesn't need it). Again, not something that libgit2 wants to use.

But maybe those are things that libgit2 should be providing to callers. Or maybe they should be spun off into their own separate utility library. But in either case, they should probably be pulled out of core git, cleaned up to make them fit for library use, and then made part of libgit2.

-Peff