Policy on global variables
John Keeping
john at keeping.me.uk
Thu Jan 16 22:21:52 CET 2014
On Thu, Jan 16, 2014 at 07:38:02PM +0100, Jason A. Donenfeld wrote:
> On Thu, Jan 16, 2014 at 2:08 PM, John Keeping <john at keeping.me.uk> wrote:
> >
> > I had a look at porting to libgit2 about a year ago and it mostly isn't
> > too bad. IIRC the only problematic area is the graph output which we
> > currently get from libgit.a but would have to do ourselves if we switch
> > to libgit2.
>
> Are there any downsides of doing this? I know we've put a lot of work
> into cozying up with internal git utility functions and their build
> system. Would we have to reimplement a lot of this? Would it be worth
> it? Are there general benefits of using libgit2 over what we have now?
> Are there general downsides?
Given the CGit and Git are both GPLv2, we could always just take
strbuf.[ch] and the argv-array bits from git.git and copy them into
CGit. Likewise the test suite could switch to using Sharness with very
little effort.
So I don't think the recent changes towards using more bits of Git
actually have too much impact here.
> More importantly, is this something you would be willing to do, if we
> decided it was the best direction?
I won't have time to do this in the near future.
The first step in this direction may actually be useful even if we stick
with embedding libgit.a. Re-writing the commit graph drawing ourselves
could allow prettier output than the ASCII we inherit from Git.
More information about the CGit
mailing list