[PATCH 0/5] cache API: always have a "istate->repo"

The "struct index_state" contains a "repo" member, which should be a pointer to the repository for that index, but which due to us constructing such structs on an ad-hoc basis in various places wasn't always available.

We'd thus end up with code like this, in the recent ds/omit-trailing-hash-in-index topic:

	struct repository *r = istate->repo ? istate->repo : the_repository;

Really we should be able to trust the "istate->repo", but were carrying those sorts of conditionals because our index might come from a manually constructed source, so we'd have to fall back to "the_repository".

This series changes the relvant code so the "repo" field is always non-NULL, as 5/5 here shows we had various workarounds in place for that, which can now go away.

See https://github.com/avar/git/tree/avar/do-not-lazy-populate-istate-repo for passing CI and a fetchable branch for this topic.

See https://lore.kernel.org/git/xmqqmt6vqo2w.fsf@gitster.g/ for previous discussion on this topic.

Ævar Arnfjörð Bjarmason (5):
  builtin/difftool.c: { 0 }-initialize rather than using memset()
  sparse-index.c: expand_to_path() can assume non-NULL "istate"
  sparse-index API: fix TODO, BUG() out on NULL ensure_full_index()
  read-cache.c: refactor set_new_index_sparsity() for subsequent commit
  treewide: always have a valid "index_state.repo" member

 apply.c                   |  2 +-
 builtin/difftool.c        |  4 +---
 builtin/sparse-checkout.c |  1 +
 builtin/stash.c           |  8 ++++----
 builtin/worktree.c        |  2 +-
 fsmonitor-settings.c      | 14 --------------
 fsmonitor.c               |  2 +-
 merge-recursive.c         |  2 +-
 read-cache.c              | 23 +++++++++--------------
 repository.c              |  2 ++
 revision.c                |  2 +-
 sparse-index.c            | 15 ++++-----------
 split-index.c             |  1 +
 unpack-trees.c            |  4 +++-
 14 files changed, 30 insertions(+), 52 deletions(-)