Am 21.03.2014 23:00, schrieb Junio C Hamano: > Johannes Sixt <j6t@xxxxxxxx> writes: > >> Add an infrastructure that simplifies adding new tests of the hunk >> header regular expressions. >> >> To add new tests, a file with the syntax to test can be dropped in the >> directory t4018. The README file explains how a test file must contain; > > s/how/what/, or "how a test file must be written" you mean? I do mean one of those, preferably the latter ;) >> -for p in ada bibtex cpp csharp fortran html java matlab objc pascal perl php python ruby tex >> +diffpatterns=" >> + ada >> + bibtex >> + cpp >> + csharp >> + fortran >> + html >> + java >> + matlab >> + objc >> + pascal >> + perl >> + php >> + python >> + ruby >> + tex >> +" >> + >> +for p in $diffpatterns >> do >> test_expect_success "builtin $p pattern compiles" ' >> echo "*.java diff=$p" >.gitattributes && > > I always found this "Let's apply rules for language $p to these > *.java files" strange. I have wonder if it makes sense to further > change the framework to read the name of the rule to be applied from > the file in t/t4018/ directory, instead of using filename that is > the same as the name of the rule? That way, you can list the files > in t/t4018/ directory to come up with the above list, without having > to maintain the list of rules separately like the above. I see what you mean. Notice, however, that we also test whether the regular expressions can be compiled successfully, and for this it is desirable to have the complete list of userdiff drivers. Until we have at least one test-case for each driver, we wouldn't get the complete list. In summary, I do agree that a bit more automation is also desirable, but we are not there, yet. -- Hannes -- 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