Re: [PATCH 5/5] maintenance: allow custom refspecs during prefetch

> On 4/9/2021 3:28 PM, Ævar Arnfjörð Bjarmason wrote:
>> 
>> On Fri, Apr 09 2021, Derrick Stolee wrote:
>> 
>>> On 4/7/2021 6:26 AM, Ævar Arnfjörð Bjarmason wrote:
>>>> I think converting the whole thing to something like the WIP/RFC patch
>>>> below is much better and more readable.
>>>
>>> This is an interesting approach. I don't see you using the ERR that you
>>> are inputting anywhere, so that seems like an unnecessary bloat to the
>>> consumers. But maybe I haven't discovered all of the places where this
>>> would be useful, but it seems better to pipe stderr to a file for later
>>> comparison when needed.
>> 
>> Yes, it's probably not a good default here. For the test-lib.sh tests
>> there's check_sub_test_lib_test and check_sub_test_lib_test_err, most of
>> the tests only test stdout.
>> 
>>>> +test_expect_process_tree () {
>>>> +	depth= &&
>>>> +	>actual &&
>>>> +	cat >expect &&
>>>> +	cat <&3 >expect.err
>>>> +	while test $# != 0
>>>> +	do
>>>> +		case "$1" in
>>>> +		--depth)
>>>> +			depth="$2"
>>>> +			shift
>>>> +			;;
>>>> +		*)
>>>> +			break
>>>> +			;;
>>>> +		esac
>>>> +		shift
>>>> +	done &&
>>> Do you have an example where this is being checked? Or can depth
>>> be left as 1 for now?
>> 
>> It can probably be hardcoded, but I was hoping someone more familiar
>> with trace2 would chime in, but I'm fairly sure there's not a way to do
>> it without parsing the existing output with either some clever
>> grep/awk-ing of the PERF output, or stateful parsing of the JSON.
>> 
>> I thought that for git maintenance tests perhaps something wanted to
>> assert that we didn't have maintenance invoking maintenance, or that
>> something expected to prune refs really invoked the relevant prune
>> command via "gc".
>> 
>>>> +	log="$(pwd)/proc-tree.txt" &&
>>>> +	>"$log" &&
>>>> +	GIT_TRACE2_PERF="$log" "$@" 2>actual.err &&
>>>> +	grep "child_start" proc-tree.txt >proc-tree-start.txt || : &&
>>>> +	if test -n "$depth"
>>>> +	then
>>>> +		grep " d$depth " proc-tree-start.txt >tmp.txt || : &&
>>>> +		mv tmp.txt proc-tree-start.txt
>>>> +	fi &&
>>>> +	sed -e 's/^.*argv:\[//' -e 's/\]$//' <proc-tree-start.txt >actual &&
>>>> +	test_cmp expect actual &&
>>>> +	test_cmp expect.err actual.err
>>>> +} 7>&2 2>&4
>>>
>>> I think similar ideas could apply to test_region. Giving it a try
>>> now.
>> 
>> Probably, I didn't even notice that one...
>
> I gave this a few hours today, and I'm giving up. I'm the first to
> admit that I don't have the correct scripting skills to do some of
> these things.
>
> I've got what I tried below. It certainly looks like it would work.
> It solves the problem of "what if the test is flaky?" by ensuring that
> all subcommands (at depth 0) match the inputs exactly.

> However, the problem comes when trying to make that work for all of
> the maintenance tests, specifically the 'incremental-repack' task.
> That task dynamically computes a --batch-size=X parameter, and that
> is not stable across runs of the script.
>
> This was avoided in the past by only checking for the first of three
> subcommands when verifying that the 'incremental-repack' task worked.
> That is, except for the EXPENSIVE test that checks that the --batch-size
> maxes out at 2g.
>
> The thing that might make these changing parameters work is to allow
> the specified lines be a _prefix_ of the actual parameters. Or, let
> each line be a pattern that is checked against that line. Issues come
> up with how to handle this line-by-line check that I was unable to
> overcome.
>
> The good news is that the idea of adding a '--prefetch' option to
> 'git fetch' makes the change to t7900-maintenance.sh much easier,
> making this change to test_subcommand less of a priority.
>
> I include my attempt here as a patch. Feel free to take whatever
> you want of it, or none of it and start over. I do think that it
> makes the test script look much nicer.