Re: [PATCH v4 07/20] test-read-cache: print cache entries with --table

On 3/29/2021 7:06 PM, Ævar Arnfjörð Bjarmason wrote:

On Mon, Mar 29 2021, Derrick Stolee wrote:

quoted

On 3/28/2021 11:31 AM, Ævar Arnfjörð Bjarmason wrote:> It seems to me that the reason for that state is based on a

quoted

misunderstanding about what we would and wouldn't add to builtin/*.c,
i.e. that we wouldn't have something like a --debug option, but as
ls-files shows that's not a problem.

At the risk of going in circles here...

quoted

I feel _strongly_ that a change to the user-facing CLI should come
with a good reason and care about how it locks-in behavior for the
future.

And I agree with you. Where we disagree is whether lives in builtin/*.c
== user-facing. I think --debug options are != that. It seems Junio
downthread agrees with that.

quoted

Any adjustment to 'git ls-files' deserves its own series and
attention[...]

A user-facing change to it yes, but I don't see how use of an (existing
even) --debug option would warrant any more attention than a new test
helper, less actually, it's less new code.

I disagree that we can change the expected output of --debug so
quickly, despite warnings in the documentation. Changing that format
or creating a new output format requires cognitive load, and we have
enough of that going on in this area as it is.

quoted

[...] not in an already-too-large series like this one.

...

I'm just still perplexed at how you keep bringing up use of an
internal-only --debug option as "user-facing", and here "already too
large" when we're talking about a proposed alternate direction that
would reduce the size.

I'm not saying "patch size" or "code size" but instead thinking of it
in terms of how many decisions need to be made. Changing a builtin
when it's not necessary adds to the complexity of the series and
interrupts its core goals.

Finally, I have mentioned that I will need extra data for testing a
new index format. I don't want to modify the builtin now in a way
that is insufficient for the needs in that future series.

Just to clarify, upthread in [1] you said:

    And I recommend that you continue to pursue [these RFC patches] as
    an independent series, but I'm not going to incorporate them into
    this one[...]

So do I understand it right that you're referring to phase IV in your
opinion being the first point where we'd consider piggy-backing on
anything in builtin (that "user-facing" dilemma again...).

I'm saying that if you feel strongly about it, then please pursue the
changes to ls-files any time after this series (but probably after
the next) solidifies. Having the changes be in a separate series allows
time to inspect the behavior change to the builtin in a focused way.
 

But at that point wouldn't you have your own ideas about some
user-facing ls-files or other porcelain for this, so I'm not sure where
to place the encouragement that I continue to pursue that RFC series,
other than setting a reminder in my calendar for 6-12 months in the
future :)

Otherwise, I will modify ls-files myself in this 6-12 month timeframe,
based on the established plan to remove the command_requires_full_index
setting.

Thanks,
-Stolee