On 3/17/2021 4:26 PM, Elijah Newren wrote: > On Wed, Mar 17, 2021 at 12:46 PM Derrick Stolee <stolee@xxxxxxxxx> wrote: >> >> On 3/17/2021 2:28 PM, Elijah Newren wrote: >>> On Wed, Mar 17, 2021 at 6:28 AM Ævar Arnfjörð Bjarmason >>> <avarab@xxxxxxxxx> wrote: >>>> >>>>> From: Derrick Stolee <dstolee@xxxxxxxxxxxxx> >> >>>> >>>> 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.) True, that is some internal information already. >> 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? Adding this justification to the commit message would definitely be helpful, so I will do that. Thanks, -Stolee
