On 07 Jan 2016, at 03:04, Jeff King [off-list ref] wrote:

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

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

quoted

On Wed, Jan 6, 2016 at 2:03 AM, Duy Nguyen [off-list ref] wrote:

quoted

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. :)

We did try to match the rules which git followed at the time when we added the functionality, but sometimes small changes in git mean large changes for us. There’s a couple of recent issues complaining that we don’t match git where *git* doesn’t quite seem to match the rules as I know them.

I don’t recall the details of how we brought ignore support in, but when we don’t just copy the code from git, it’s generally because it’s embedded into the rest of the code, or in some other way doesn’t make a lot of sense in a library API.

We do (at least I do) want to test libgit2 more against the git test suite; this either involves porting it to our test suite (generally non-trivial since we can’t use shell, making it harder to compare) or creating a command which pretends to be git but uses libgit2. The latter is what I think we’ll have to do, as we keep hitting complex pieces which git keeps changing like crlf and ignore handling. There’s been plans to do this, but it’s never been the top priority.

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).

quoted

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.

Yeah, we currently use the fnmatch code from Android IIRC. I’m not looking forward to writing a variant of that for double-star. If the wildmatch authors are receptive to allowing the linking exception, that would be ideal.

   cmn