Subject: Re: move some test-tools to 'unstable plumbing' built-ins

From: Taylor Blau <[email-masked]>
Date: Mon, 8 Nov 2021 17:06:47 -0500

On Mon, Nov 08, 2021 at 09:19:10PM +0100, Ævar Arnfjörð Bjarmason wrote:
>
> On Mon, Nov 08 2021, Junio C Hamano wrote:
>
> > Taylor Blau <[email-masked]> writes:
> >
> >> In my experience I *rarely* rely on test-helpers when debugging wedged
> >> repositories, and much more often end up either in gdb, or in an
> >> anonymized copy of the repository on a different server. I would imagine
> >> that others have similar experiences.
> >>
> >> So unless we had a much more compelling reason to have the test helpers
> >> more readily available, I do not think that the risk our users will
> >> begin to depend on these unstable tools is worth taking.
> >
> > OK.  It sounds like a sensible argument against such a change.
>
> It's an argument against not flipping "make installing them be optional"
> flag on by default, but we could otherwise move some of t/helper to
> builtin/, which would help by encouraging us to write at least
> boilerplate docs for them.
>
> Git developers & similar parties could then set them to be installed for
> ad-hoc debugging.

I was talking about users not heeding our warning, but I'm still not
really that compelled by making the test-helpers an optional component
in our build.

I am pretty sure I have only reached for the test-helpers less than half
a dozen times over the years, and *much* more often find myself in a
debugger. If I'm in the minority (and there really are a lot of
administrators who find it useful to have the test-tools on hand), then
that is a different story, but my guiding assumption is that that isn't
the case.

> I really don't buy the argument that there's no amount of warnings in
> our documentation that we can include which would give us future license
> to willy-nilly change certain things.

My point was only that we cannot guarantee that users read or care about
our documentation.

Thanks,
Taylor