From mboxrd@z Thu Jan 1 00:00:00 1970 From: john at keeping.me.uk (John Keeping) Date: Thu, 16 Jan 2014 21:21:52 +0000 Subject: Policy on global variables In-Reply-To: References: <20140116005912.GA20306@dcvr.yhbt.net> <20140116104751.GA26678@dcvr.yhbt.net> <20140116130844.GF7608@serenity.lan> Message-ID: <20140116212152.GH7608@serenity.lan> 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 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.