Re: [JGIT PATCH v4] Implementation of fnmatch and the ignore rules

[Robin Rosenberg <robin.rosenberg.lists@dewire.com>]

fredagen den 13 juni 2008 20.30.34 skrev Florian Köberle:
> Hi
> 
> Thanks for the suggestions and comments, the new patches are available here:
> http://repo.or.cz/w/egit/florian.git?a=shortlog;h=refs/heads/mailinglist-patches-4
> 
> I will send them as a reply to this email soon.
> 
> 
> The most noticeable change is that I improved the fnmatch functionality.
> 
> All character classes of the type [:class:] work now.
> Other character classes, including the character classes [=class=] and
> [.class.] will cause a InvalidPatternException. The last two aren't
> supported at my bash neighter, but are defined in the POSIX standard.
> 
> Two other implementation differences are:
> 
> The bash shell doesn't support the full range of digits, but my
> implementatiton does. e.g. ۹ (U+06F9 EXTENDED ARABIC-INDIC DIGIT NINE)

Interesting. I'm not sure what to say here. Full compatibility with Git or "better"?

> A pattern like [[:] results in a InvalidPatternException in my
> implementation. The shell has there a strange behavior: if the files "["
> and ":" exists then "ls [[:]" shows only ":".

Having : in  a filename is asking for trouble. I think the parser thinks [[: as 
in [[:alpha:]] and break the parsing somhow. This is possibly even undefined,
so I think you should disallow this. [[\:] works in bash btw.

> The other main change is that I introduced a AbstractTestCase class
> which which offers functionality to create temporary folders.
> RepositoryTestCase extends now from this new class.
> 
> An other patch reducing the duplication between AbstractTestCase and
> RepositoryTestCase class will follow soon, if you like the change.

Not trying to clean up got me into trouble with tons and tons of garbage, that
is why I placed new repos in a directory and try to delete it if possible. That
ofcourse excludes parallell runs. Anyone with a good idea on how to
really handle this?

> I also updated all license statements to the 3-clause BSD.
> 
> Even if you don't like the last change (the AbstractTestCase change) it
> would be cool if you would accept at least some patches.

The patch constituents are somwehat loose. Would this rebase do?

pick e331b13 Added the package fnmatch and two exceptions.
squash 64d8aa2 Added the interface FilePattern.
squash ae7915f Added the class Rule.
squash 48496f5 Added the interface Rules.
squash d7f58cb Added the class FileNamePattern.
squash f757bf1 Added the class FilePathPattern.
pick 39ea57e Added the class IgnoreRuleListFactory.
squash b61bf41 Added a Rules interface implementation and a factory for it.
pick f1c6c47 Added test class OverallIgnoreRulestest.
pick 5321c90 Formatted Constants class.
pick b59c160 Added constant REPOSITORY_DIRECTORY_NAME to Constants class.
squash 435b176 Added path related constants to the Constants class.
pick 76ad8d2 Added the class NoGitRepositoryFoundException.
pick 0164c9e Formatted Repository class.
pick fab1279 Added WorkTree class which can be constructed over Repository.
squash afda1f4 Added findWorkTree method to Repository class.
pick eb61f60 Formatted RepositoryTestCase.
pick 5aca2f0 Added a super class for RepositoryTestCase with a createTemporaryDirectory() method.
pick 9b6a188 Added the class LightFileTreeIterator and a test for it.
squash c9a4795 Added class LightFileTreeIterable.
pick 3b068aa Added the class PathNotInProjectDirectoryException.
pick ef7be7f Added the class AddRuleListFactory.
squash 0b81a9c Added class AddRulesFactory.
pick 9bbb0c3 Added the test class AddCommandIterationTest.

This groups patches into related chunks.

I had to run native2ascii -encoding UTF-8 on FileNameMatcherTest.java to make it pass. The reason
ofcourse is that java doesn't specify a source file encoding. You can tell javac which encoding to use,
but I think we better avoid it. For author names in comments I think we have no choice but to state
that UTF-8 is the one and only encoding for comments and documentation where ascii is unavoidable.

native2ascii does these kinds of things

        public void testWordroupCase1() throws Exception {
-               assertMatch("[[:word:]]", "ö", true, false);
+               assertMatch("[[:word:]]", "\u00f6", true, false);
        }

-- robin