Re: [RFC PATCH v5] Implement --first-parent for git rev-list --bisect

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 25, 2018, 17:33 UTC
Message-ID: <xmqq4lhqpy80.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <20180622123945.68852-1-tiagonbotelho@hotmail.com>

Tiago Botelho <tiagonbotelho@gmail.com> writes:

Show 18 quoted lines

> +test_expect_success "--bisect-all --first-parent" '
> +cat >expect1 <<EOF &&
> +$(git rev-parse CC) (dist=2)
> +$(git rev-parse EX) (dist=1)
> +$(git rev-parse D) (dist=1)
> +$(git rev-parse FX) (dist=0)
> +EOF
> +
> +cat >expect2 <<EOF &&
> +$(git rev-parse CC) (dist=2)
> +$(git rev-parse D) (dist=1)
> +$(git rev-parse EX) (dist=1)
> +$(git rev-parse FX) (dist=0)
> +EOF
> +
> +git rev-list --bisect-all --first-parent FX ^A >actual &&
> +  ( test_cmp expect1 actual || test_cmp expect2 actual )
> +'

I hate to say this, but the above looks like a typical unmaintainable mess.

What happens when you or somebody else later needs to update the graph to be tested to add one more commit (or even more)? Would it be enough to add another "rev-parse" plus "dist=X" line in both expects? Or do we see a trap for combinatorial explosion that requires us to add new expect$N?