Derrick Stolee <stolee@xxxxxxxxx> 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.
