Policy on global variables

[john at keeping.me.uk (John Keeping)]

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.