Thread (184 messages) flat view 184 messages, 6 authors, 2021-04-01

Re: [RFC/PATCH 0/5] Re: [PATCH v3 07/20] test-read-cache: print cache entries with --table

From: Elijah Newren <hidden>
Date: 2021-03-17 20:27:29

On Wed, Mar 17, 2021 at 12:46 PM Derrick Stolee [off-list ref] wrote:
On 3/17/2021 2:28 PM, Elijah Newren wrote:
quoted
On Wed, Mar 17, 2021 at 6:28 AM Ævar Arnfjörð Bjarmason
[off-list ref] wrote:
quoted
quoted
From: Derrick Stolee <redacted>
quoted
quoted
So we have a test tool that's mostly ls-files but mocks the output
ls-tree would emit, won't these tests eventually care about what stage
things are in?

What follows is an RFC series on top that's the result of me wondering
why if we're adding new index constructs we aren't updating our
plumbing to emit that data, can we just add this to ls-files and drop
this test helper?

Turns out: Yes we can.
I like the idea of having ls-files be usable to show the entries that
are in the index; that seems great to me.  I very much dislike the
--sparse flag to ls-files, as noted on that commit.
I don't like this idea. I don't think exposing internal structures
like this is something we want to do so quickly.
Not sure I follow; ls-files was already about exposing three bits of
internal structures for index entries: mode, hash, and stage number.
These are quantities that are well-defined for sparse directories too.
It would not be exposing any new or different internal structures, nor
changing the output format.  (Ævar changed the tests to not look for
"tree" but to look for the "040000" mode number.)
 Further, I intend
to use this test tool in the future to _also_ show the stored stat()
data, which would be inappropriate here in ls-files.

I would prefer to continue using the test helper here and leave
functional changes to ls-files be considered independently.
Well, I was okay with it being in a test helper regardless of whether
it could be done with ls-files, and then just circling back and fixing
up ls-files later.  But perhaps it's worth calling out in the commit
message about your plans to add stat() data and how that future piece
can't be done in ls-files (without functional changes of some sort)
just to make it clearer why we're using a test helper instead of
front-loading the port of ls-files over to sparse-indexes?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help