Re: [PATCH v4 8/7] wildmatch test: skip file creation tests on Windows proper

From: Adam Dinwoodie <adam@dinwoodie.org>
Date: Jan 10, 2018, 10:38 UTC
Message-ID: <20180110103832.GA4018@dinwoodie.org>
In-Reply-To: <20180110090724.GA2893@ash>

On Wednesday 10 January 2018 at 04:07 pm +0700, Duy Nguyen wrote:

Show 17 quoted lines

> On Mon, Jan 08, 2018 at 01:25:04PM +0100, Johannes Schindelin wrote:
> > I agree that it would make a ton of sense to use a proper, portable test
> > framework written in pure, portable C.
> > 
> > However, this ship has long sailed, hasn't it?
> 
> If you meant converting the whole test suite, oh yeah that's not gonna
> happen. But it's still possible to have some tests written in C.
> 
> I played a bit with this. The assumption is if it's agreed that we can
> get something bare bone (but functional) in then we could start having
> more and more C-based unit tests in future and also improve the C
> framework to be on par with shell one on the side.
> 
> There are still some minor problems with my patch, and a bunch of
> optional features not supported. But the numbers looks unexpectedly
> promising. 0.7 seconds on the shell version and 0.03 on the C one.

I see even more promising results from a single run on one of my Cygwin systems: from 21.3 seconds for t3070 to 0.112 seconds for your t3071. I expect there's a similar improvement in Dscho's Git for Windows environment.

> One disadvantage of this though, if this kind of framework does not
> get popular, then any new test feature must be added at both places
> but it's a waste of time to support both. So...

I don't follow: if we end up implementing every test twice, as we have here, then I agree, but I don't think there's much value in doing that except as a proof of concept, as in this immediate discussion. The obvious-to-me way to do this would be following the precedent of the core code: gradually migrate things away from shell code to C code.

Adam