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

[Derrick Stolee <stolee@gmail.com>]

On 3/29/2021 7:06 PM, Ævar Arnfjörð Bjarmason wrote:
> 
> On Mon, Mar 29 2021, Derrick Stolee wrote:
> 
>> 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
>>> 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...
> 
>> 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.
> 
>> 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.

>> [...] 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