Derrick Stolee [off-list ref] 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.
On 10/17/2021 1:58 AM, Junio C Hamano wrote:
Derrick Stolee [off-list ref] writes:
quoted
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.
quoted
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.
This statement is true.
* 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
This is only half true. If "index.sparse=false", then a sparse
index will be expanded to full upon reading. If "index.sparse=true"
then nothing special will happen to an index on reading.
What your summary above is saying is very much different.
Yes, these are different things. It also gets around the concern that
"if we have a non-integrated command, then index.sparse=true would
convert a full index to a sparse one, only to be expanded again".
That doesn't happen if we only convert from full to sparse on write.
Thanks,
-Stolee