Re: [PATCH] commit: fall back to full read when maybe_tree is NULL

> When we load a commit object from the commit graph (rather than reading
> the object contents), we don't fill in its "maybe_tree" entry, but
> rather wait to lazy-load it. This goes back to 7b8a21dba1 (commit-graph:
> lazy-load trees for commits, 2018-04-06), and saves the work of
> instantiating tree objects that nobody cares about.
>
> But it creates a data dependency: now the commit struct depends on the
> graph file to do that lazy load. This is a problem if we close the graph
> file; now we have a commit struct that claims to be parsed but is
> missing some of its data.
>
> It's rare for this to be a problem in practice, because we don't tend to
> close the graph files at all, and if we do we don't tend to look at
> their commits afterward. But there is one case that is easy to trigger:
> git-clone's --dissociate option will close the object database before
> running the dissociate repack, and then afterwards still try to check
> out the working tree. This will yield an error like:
>
>   fatal: unable to parse commit b29edc0babef41810f7b1c9ee1d74058f22e4080
>   warning: Clone succeeded, but checkout failed.
>
> What happens is that we expect repo_get_commit_tree() to lazy-load the
> tree, but commit_graph_position() returns COMMIT_NOT_FROM_GRAPH because
> the position slab has gone away (and even if it hadn't, we don't have
> the graph file itself available anymore).
>
> Let's try harder to find the tree in repo_get_commit_tree() by actually
> opening the commit object and parsing the tree line. This is extra work,
> but no more than we'd have to go to if we hadn't done the initial graph
> load in the first place.