On Mon, Jun 23, 2025 at 6:56 AM Jeff King <peff@xxxxxxxx> wrote:
> The "seq" tool has a "-f" option to produce printf-style formatted
> lines. Let's teach our test_seq helper the same trick. This lets us get
> rid of some shell loops in test snippets (which are particularly verbose
> in our test suite because we have to "|| return 1" to keep the &&-chain
> going).
>
> Signed-off-by: Jeff King <peff@xxxxxxxx>
> ---
> diff --git a/t/t0612-reftable-jgit-compatibility.sh b/t/t0612-reftable-jgit-compatibility.sh
> @@ -112,14 +112,11 @@ test_expect_success 'JGit can read multi-level index' '
> - awk "
> - BEGIN {
> - print \"start\";
> - for (i = 0; i < 10000; i++)
> - printf \"create refs/heads/branch-%d HEAD\n\", i;
> - print \"commit\";
> - }
> - " >input &&
> + {
> + echo start &&
> + test_seq -f "create refs/heads/branch-%d HEAD" 10000 &&
> + echo commit
> + } >input &&
I had suggested[1] an effectively equivalent change to Patrick for a
couple tests in the nearby t0610, but he rejected[2] the idea due to
the pure-shell version being significantly slower than the `awk`
version.
Pondering his response today, I wondered if it would make sense to
replace our pure-shell `test_seq` with an implementation via `awk`,
however, if most of our sequence vend only a small set of numbers,
then the startup cost of `awk` would probably swamp any savings,
especially on Windows where process startup is extremely slow. Taking
that into account, I further wondered if we could see an overall win
by taking a hybrid approach in which we employ the pure-shell version
if vending a small set of numbers, but fall over to an `awk` version
if vending a lot of numbers, especially as in the test above or the
tests in t0610. Anyhow, food for thought, or not, if you're not hungry
for thought food.
[1]: https://lore.kernel.org/git/CAPig+cSC3zdur1fCsa7RMNZDcgUK4pUGKb22tpgdANxR6OxNMA@xxxxxxxxxxxxxx/
[2]: https://lore.kernel.org/git/Z-FUNgmY9hTsnzds@xxxxxx/
