On 07 Jan 2016, at 03:04, Jeff King <peff@xxxxxxxx> wrote:
> [+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@xxxxxxxxx> 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. :)
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).
>
>> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html