Re: move some test-tools to 'unstable plumbing' built-ins (was: [PATCH] test_bitmap_hashes(): handle repository without bitmaps)

> > On the test-tool vs. plumbing thing: I think there are some compelling
> > reasons in either direction. There's no *good* home for these in our
> > current set of plumbing tools. E.g., the closest example we have is `git
> > rev-list --test-bitmap <rev>`, which is kind of ugly. When we needed
> > these new inspection tools for some of the newer bitmap-related tests,
> > adding them via the test-helper suite was a conscious choice to not
> > build on the ugliness of `--test-bitmap`.
> >
> > But on occasion these test-tool things are useful to have "in the
> > field", as you say. It's rare enough that I usually just clone a copy of
> > our fork as needed and build it when I do find myself reaching for
> > test-helpers.
>
> As part of the proposed integration for "scalar" I added a category to
> the command-list.txt called "optionalcontrib", which we'll list on its
> own in "man git" as (paraphrasing) super-duper-experimental.
>
> I really don't see why we shouldn't do so very lightly with some of
> these remotely-useful test-tool tools.
>
> It's pretty much the same amount of work to create a new built-in as a
> new test-tool, and as long as we make it clear in our documentation that
> these aren't in the same "plumbing" category I don't see why we
> shouldn't add those quite freely.

> It seems to me that we've ended up with the current status quo of not
> adding "new plumbing" because we'll need to support it forever out of
> some self-imposed constraint that we couldn't add new categories to the
> "git" manual page.
>
> But if we just prominently list them as being unstable helpers aimed at
> git experts, and note the same thing prominently in their manual page
> (trivially done via an include) everyone should be on the same page
> about their stability, and we'll be able to use stuff like "test-tool
> pkt-line" "in the field".