Re: Git 2.7.0 gitignore behaviour regression

[Jeff King <peff@peff.net>]

[+cc Carlos and Shawn for libgit2/JGit talk]

On Wed, Jan 06, 2016 at 10:58:37AM -0800, Junio C Hamano wrote:

> On Wed, Jan 6, 2016 at 2:03 AM, Duy Nguyen <pclouds@gmail.com> wrote:
> >
> > Yeah.. it looks like libgit2's gitignore support was written new, not
> > imported from C Git, so behavior differences (especially in corner
> > cases) and even lack of some feature ("**" support comes to mind). For
> > isolated features like gitignore, perhaps we can have an option to
> > replace C Git code with libgit2 and therefore can test libgit2 against
> > C Git test suite. It could be a good start for libgit2 to invade C
> > Git. Not sure if anybody's interested in doing it though.

Yeah, libgit2 is in the difficult position of trying to hit a moving
target. There's a good chance that it _was_ the same as git's behavior
when it was written. :)

JGit is in the same boat, and I wouldn't be surprised if they don't
handle "**" either (I didn't check). Note that git inherited that
feature (and probably some others) by importing a GPLv2 version of
wildmatch. That certainly isn't an option for JGit (because it's not
pure Java), and probably not for libgit2 (which would need the wildmatch
authors to grant the linking exception).

> Yup, an area that is reasonably isolated from the remainder of the system like
> this might be a good starting point. But I suspect that the invasion needs to
> happen in the opposite direction in this particular case before it happens.
> That is, if libgit2's implementation does not behave like how we do, it needs to
> be fixed, possibly by discarding what they did and instead importing code from
> us. After the behaviour of libgit2 is fixed, we can talk about the
> invasion in the
> opposite direction.

Unfortunately, "importing code from us" is not so easy. :(

They'll either need to contact the wildmatch authors, or rewrite
wildmatch from scratch.

-Peff