t7008.12 is marked as an expected failure, but building Git on Cygwin including a `make configure && ./configure` step has the test unexpectedly passing. Building without the configure step has the test failing as expected. This appears to be behaviour specific to Cygwin; at least I get that test failing on my CentOS box regardless of whether I perform the configure step. The "problem" here is `git grep` is matching a null byte with a "."; the test implies that ought to work in theory but hasn't worked in practice since the test was added in v1.7.1-101-gf96e567. The commit message there asserts "NUL characters themselves are not matched in any way, though", which is evidently not the case on Cygwin, provided the `configure` script is run. I'm not sufficiently familiar with the standards and library interfaces here to have any idea what the "correct" regex behaviour in this circumstance is. I'm not sure what the correct thing to do in the face of such an unexpected test pass; it looks as though Cygwin Git's `grep` is going to behave in a subtly different way to Git on other platforms as a result of this, which is probably not ideal, but I don't know if there's anything that "ought" to be done to either ensure consistent behaviour across platforms, or to stop marking the test as an expected failure on platforms where it passes. Adam -- 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