On Fri, Jan 06 2023, Derrick Stolee wrote: > On 1/6/2023 5:45 PM, Junio C Hamano wrote: >> Derrick Stolee <derrickstolee@xxxxxxxxxx> writes: >> >>> After investigating some of the failures from creating a BUG() statement >>> when istate->repo is NULL I see several problems, and they are not related >>> to submodules for the most part. >>> >>> The first issues I've found are due to code paths that operate on the_index >>> without actually initializing it with a do_read_index(), or otherwise >>> initialize an index using a memset() instead of a common initializer. This >>> looks to be a frequent enough problem that solving it would require a >>> significant effort. It's not a quick fix. >> >> Thanks. It is not entirely unexpected X-<, considering how the >> connection from the in-core repository and the in-core index has >> been developed and evolved. So in short, istate->repo is not yet >> ready to be used, until the problems you identified are resolved? >> >> We probably should start paying down such technical debts. We've >> punted on them too many times, saying "yes this is klunky but what >> we have is good enough for adding this feature", I suspect? > > Yes, I'll make note to prioritize this soon. I noted in passing in [1] that I had those patches locally, if I'm understanding you correctly and you're planning to work on changes that'll make "istate->repo" always non-NULL. I've rebased those on top of your "ds/omit-trailing-hash-in-index". I'm CI-ing those now & hoping to submit them soon (I've had it working for a while, but there was some interaction with your patches). Preview at [2]. 1. https://lore.kernel.org/git/221215.865yec3b1j.gmgdl@xxxxxxxxxxxxxxxxxxx/ 2. https://github.com/avar/git/compare/avar-ds/omit-trailing-hash-in-index...avar/do-not-lazy-populate-istate-repo
