Re: [PATCH] t3701: two subtests are fixed

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

[-- Attachment #1: Type: text/plain, Size: 2903 bytes --]

Hi Junio,

I did not want to spend more brain cycles about this, but since you left a
few questions hanging...

On Tue, 21 Jun 2022, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> >> in config.mak. Nothing else strikes me as potentially relevant.
> >>
> >> Ævar noticed this and has a better version of my patch, I think.
> >
> > So you did not find it utterly rude and presumptuous that somebody sent a
> > new iteration of your patch without even so much as consulting with you
> > whether you're okay with this? I salute your forbearance, then.
>
> I had an impression that these (wasn't there another one) were
> independent discoveries and patching that happened at the same time.

If this was the first time an unsolicited iteration was sent on another
contributor's behalf, I would be able to give the benefit of the doubt.
Even if it was the second or third time. It's been many more times,
though. And it is not leaving the impression of an inviting, welcoming
culture I would like to see on the Git mailing list. But it's your
project to lead, not mine, therefore I have no say in this.

> > -- snip --
> > diff --git a/t/t3701-add-interactive.sh b/t/t3701-add-interactive.sh
> > index 94537a6b40a..6d1032fe8ae 100755
> > --- a/t/t3701-add-interactive.sh
> > +++ b/t/t3701-add-interactive.sh
> > @@ -538,7 +538,9 @@ test_expect_success 'split hunk "add -p (edit)"' '
> >  	! grep "^+15" actual
> >  '
> >
> > -test_expect_failure 'split hunk "add -p (no, yes, edit)"' '
> > +test_lazy_prereq BUILTIN_ADD_I 'test_bool_env GIT_TEST_ADD_I_USE_BUILTIN true'
> > +
> > +test_expect_success BUILTIN_ADD_I 'split hunk "add -p (no, yes, edit)"' '
> >  	test_write_lines 5 10 20 21 30 31 40 50 60 >test &&
> >  	git reset &&
> >  	# test sequence is s(plit), n(o), y(es), e(dit)
>
> Prerequisite lets you skip.

Yes. It lets you skip a test for a known breakage in code we're never
going to fix because we're going to delete it instead, for example. Saving
some electricity, too, by avoiding to run said test case.

> > @@ -562,7 +564,7 @@ test_expect_success 'split hunk with incomplete line at end' '
> >  	test_must_fail git grep --cached before
> >  '
> >
> > -test_expect_failure 'edit, adding lines to the first hunk' '
> > +test_expect_failure BUILTIN_ADD_I 'edit, adding lines to the first hunk' '
>
> I am not sure if this is a good change, quite honestly.  With
> s/failure/success/, perhaps, but not in the posted form.

Indeed, this was an oversight on my part, as you might have guessed from
the `failure` being replaced with `success` in the previous hunk. I simply
forgot it here.

But a more complicated solution for the same problem was applied directly
to the main branch, so I'd like to shift my attention to problems where my
input has a chance of mattering.

Ciao,
Dscho