On Wednesday 10 January 2018 at 04:07 pm +0700, Duy Nguyen wrote:
> 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

Reply via email to