Re: [PATCH 2/2] merge-base: "--reflog" mode finds fork point from reflog entries

[Junio C Hamano <gitster@pobox.com>]

Eric Sunshine <sunshine@sunshineco.com> writes:

> On Thu, Oct 24, 2013 at 5:26 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Eric Sunshine <sunshine@sunshineco.com> writes:
>>
>>> On Thu, Oct 24, 2013 at 3:11 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>>> diff --git a/t/t6010-merge-base.sh b/t/t6010-merge-base.sh
>>>> index f80bba8..3a1abee 100755
>>>> --- a/t/t6010-merge-base.sh
>>>> +++ b/t/t6010-merge-base.sh
>>>> @@ -230,4 +230,31 @@ test_expect_success 'criss-cross merge-base for octopus-step' '
>>>>         test_cmp expected.sorted actual.sorted
>>>>  '
>>>>
>>>> +test_expect_success 'using reflog to find the fork point' '
>>>> +       git reset --hard &&
>>>> +       git checkout -b base $E &&
>>>> +       (
>>>> +               for count in 1 2 3 4 5
>>>> +               do
>>>> +                       git commit --allow-empty -m "Base commit #$count" &&
>>>> +                       git rev-parse HEAD >expect$count &&
>>>> +                       git checkout -B derived &&
>>>> +                       git commit --allow-empty -m "Derived #$count" &&
>>>> +                       git rev-parse HEAD >derived$count &&
>>>> +                       git checkout base &&
>>>> +                       count=$(( $count + 1 )) || exit 1
>>>> +               done
>>>
>>> Did you want && here?
>>
>> No, I did not.  Can't you tell from the fact that I didn't put one
>> there ;-)?
>>
>> It does not hurt to have one there, but it is not necessary.
>>
>> Because the loop itself does not &&-cascade from anything else, the
>> only case anything after "done &&" would be skipped and making the
>> whole thing fail would be when anything inside the loop fails, but
>> we already "exit 1" to terminate the whole subprocess in that case,
>> so we will not continue past the loop.
>
> I didn't read inside the loop closely enough to see that. Sorry
> for the noise.

Heh, you helped me realize that the above was suboptimal, and it
wasn't a noise ;-)

We could do it this way without the subshell and the exit, I would
think.

test_expect_success 'using reflog to find the fork point' '
	git reset --hard &&
	git checkout -b base $E &&
	for count in 1 2 3 4 5
	do
		git commit --allow-empty -m "Base commit #$count" &&
		git rev-parse HEAD >expect$count &&
		git checkout -B derived &&
		git commit --allow-empty -m "Derived #$count" &&
		git rev-parse HEAD >derived$count &&
		git checkout base &&
		count=$(( $count + 1 )) || break
	done &&

	for count in 1 2 3 4 5
	do
		git merge-base --reflog base $(cat derived$count) >actual &&
		test_cmp expect$count actual || break
	done &&

	# check defaulting to HEAD
	git merge-base --reflog base >actual &&
	test_cmp expect5 actual
'

To the earlier code, somebody could add

                (
        +               more setup code &&
        +               yet more setup code &&
                        for count in 1 2 3 4 5

inside the subshell and we would fail to notice fairlure from the
new setup code if we didn't have && after the first "done".  There
is much less risk of that kind of breakage if we did the loop
without subshell and exit and instead with the usual &&-cascade.

Thanks.