Subject: Re: [PATCH 2/2] sparse-index: update index read to consider index.sparse config

From: Junio C Hamano <[email-masked]>
Date: Sat, 16 Oct 2021 22:58:03 -0700

Derrick Stolee <[email-masked]> writes:

> I think you are slightly mistaken here: If index.sparse=true, then a
> full index will be converted to one on write, but not immediately upon
> read. This means that subsequent commands will read a sparse index, and
> they will either benefit from that or not depending on whether they are
> integrated with the sparse index or not.
>
> The new behavior here is that if index.sparse=false, then we convert
> a sparse index to a full one upon read, avoiding any chance that a
> Git command is operating on a sparse index in-memory.

And if index.sparse=true, then we convert a full on-disk index to a
sparse one in-core upon reading, right?  My comment was solely on
that side of the picture, not on the "index.sparse is set to false
so we automatically expand" case.

> The simplest summary I can say is here:
>
> * If index.sparse=false, then a sparse index will be converted to
>   full upon read.
>
> * If index.sparse=true, then a full index will be converted to sparse
>   on write.

Oh, I see, so yes I was very much misunderstanding what you guys are
trying to do.  I somehow thought that sparse-to-full and
full-to-sparse conversions (1) already happen on the write codepath,
and (2) this patch makes them both happen also on the read codepath.

IOW:

    * If index.sparse=false, a sparse index will be written as full,
      and if it is true, a non-sparse index will be written as
      sparse, even before these patches.

    * In addition, with these patches, if index.sparse=false, a
      sparse index will be expaned to full upon reading, and if it
      is true, a non-sparse index will be shrunk to sparse upon
      reading

was what I was expecting.

What your summary above is saying is very much different.