Re: [PATCH 2/2] sparse-index: update index read to consider index.sparse config
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Oct 17, 2021, 05:58 UTC
- Message-ID
- <xmqq5ytw19ck.fsf@gitster.g>
- In-Reply-To
- <e17b7e0f-edf0-0770-9b9b-dd092a8a7a41@gmail.com>
Derrick Stolee <stolee@gmail.com> writes:
Show 9 quoted lines
> 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.
Show 7 quoted lines
> 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
readingwas what I was expecting.
What your summary above is saying is very much different.