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. 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. Any adjustment to 'git ls-files' deserves its own series and attention, not in an already-too-large series like this one. I'm not happy that this series and the next are so long, but that's the best I can do to make them reviewable and still capture a complete scenario. Hopefully the remaining series after these first two are smaller. Things like "what should 'git ls-files' do with a sparse index?" can fit cleanly on top once the core functionality of the internals are stable. I have an _opinion_ that the ls-files output is not well-suited to testing because the --debug output splits details across multiple lines. This is a minor point that could probably be corrected by a complicated script method, but that's why I list this as an opinion. > I mean it's fine if it's just a "I don't think this is important and > don't want to spend time on it, but it seems like a good idea", in which > case others have the option of re-rolling some of these patches if they > care (at this point I wouldn't). > > Or "this is just a bad idea for XYZ reason", which is also fine, and > even more valuable to document for future work in the area. > > But to have another series built on this with refactorings back and > forth before code's landed on master just seems like needless churn. I think changing 'ls-files' before the sparse index has stabilized is premature. I said that a series like the RFC you sent would be appropriate after this concept is more stable. I do _not_ recommend trying to juggle it on top of the work while the patches are in flight. Thanks, -Stolee
