Jeff King <peff@xxxxxxxx> writes: >> But I think I've been losing that argument recently, e.g. after [1] >> (which I argued we should put into git-ls-files) even things like git's >> basic idea of the state of the index are exposed in some helpers, but >> not corresponding plumbing. > > Yeah. I wish "ls-files --debug" showed more of the extension data, for > example. Let me second that ;-) With extensions and even more drastic things like sparse index entries, "pretend that the index is a flat list of <mode, object, path>" is sometimes not useful in debugging (as bugs and design mistakes might lie in the code that makes us pretend). Even with packed objects, we still "pretetend that an object file is a single line '<type> SP <len> NUL' followed by payload bytes, deflated", as if packed objects do not exist. I do not offhand recall we have a good debugging option in the plumbing, or a dedicated debugging tool, but because the format for packed objects has been stable, we are probably OK. Contrast to that, the index is designed to be more ephemeral and its format is subject to change, so we may in more need for a good debugging option. > Yeah, I'd agree with that. The most valuable helpers to me are the ones > that help us understand what Git is seeing, or what's in a binary file > format. Obscure-case "functional" helpers are less likely to be > generally useful. Yup
