Re: [PATCH 2/2] merge-recursive: fix merging a subdirectory into the root directory

From: Elijah Newren <newren@gmail.com>
Date: Oct 25, 2019, 00:12 UTC
Message-ID: <CABPp-BHBUKq73Ru3D9HKp6ABo8eQNmkSkz6MjA+4J2a6xxtWjA@mail.gmail.com>
In-Reply-To: <nycvar.QRO.7.76.6.1910250020220.46@tvgsbejvaqbjf.bet>

On Thu, Oct 24, 2019 at 3:23 PM Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

Show 27 quoted lines

>
> Hi Elijah,
>
> On Tue, 22 Oct 2019, Elijah Newren wrote:
>
> > [...]
> > Yes, t6043 is pretty long code-wise, and still has over five dozen
> > tests after ditching the separate "setup" tests -- but all of those
> > tests still run in 3.6s on my box. [...]
>
> $ time sh t6043-*.sh --quiet
> not ok 74 - 9g-check: Renamed directory that only contained immediate subdirs, immediate subdirs renamed # TODO known breakage
> not ok 87 - 10e-check: Does git complain about untracked file that is not really in the way? # TODO known breakage
> # still have 2 known breakage(s)
> # passed all remaining 117 test(s)
> 1..119
>
> real    7m22.393s
> user    0m52.115s
> sys     3m53.212s
>
> And this is not a slow box. So yes, those extra spawned processes? They
> accumulate. Spawning processes is what Linux was optimized for. You're
> optimizing for Linux.
>
> Ciao,
> Dscho

Wow, I knew it'd be slower on other platforms but I certainly didn't expect a factor of 122; you've made me eat my words about performance for this case.

Still, I rely pretty heavily on t6036, t6042, t6043, and t6046 for sanity in the face of refactoring and rewriting -- and as mentioned before they have caught refactoring bugs in those areas that appear at first blush as "overzealous", and have done so multiple times. So, what's the alternative -- mark the tests as linux only? Do that but also add a second copy that is trimmed down so other platforms can run that one? Keep a local copy of all these tests? Jump on the our-testing-pyramid-is-inverted bandwagon when it materializes and provides a way to write unit tests instead of just end-to-end tests (I'm game for that one...)? Start discussing crazy ideas like a busybox-like shell, possibly with git extensions (a "git shell" if you will, though I know the name is already taken), just for running the git testsuite faster? Those alternatives all sound either unappealing or like very large projects that'll take a while to materialize (and which I certainly won't be spearheading; I've got too many big backburnered projects already). This performance is clearly bad, but gutting the tests isn't tenable either.