Re: [PATCH v3 02/12] sparse-index: include EXTENDED flag when expanding

From: Derrick Stolee <stolee@gmail.com>
Date: May 18, 2021, 14:57 UTC
Message-ID: <ddeda8ec-bc21-1f62-5d0e-839be74f1ec8@gmail.com>
In-Reply-To: <CABPp-BFx9=7j5LrLnQwzxba+i7_cAEXngzyt9rfOJfBuqOPBsw@mail.gmail.com>

On 5/17/2021 9:33 PM, Elijah Newren wrote:

Show 21 quoted lines

> On Fri, May 14, 2021 at 11:31 AM Derrick Stolee via GitGitGadget
> <gitgitgadget@gmail.com> wrote:
>>
>> From: Derrick Stolee <dstolee@microsoft.com>
>>
>> When creating a full index from a sparse one, we create cache entries
>> for every blob within a given sparse directory entry. These are
>> correctly marked with the CE_SKIP_WORKTREE flag, but they must also be
>> marked with the CE_EXTENDED flag to ensure that the skip-worktree bit is
>> correctly written to disk in the case that the index is not converted
>> back down to a sparse-index.
> 
> This seems odd to me.  When sparse-index is not involved and we are
> just doing simple sparse checkouts, do we mark CE_SKIP_WORKTREE
> entries with CE_EXTENDED?  I can't find any code that does so.
> 
> Is it possible that the setting of CE_EXTENDED is just a workaround
> that happens to force the index to be written in cases where the logic
> is otherwise thinking it can get away without one?  Or is there
> something I'm missing about why the CE_EXTENDED flag is actually
> needed here?

This is happening within the context of ensure_full_index(), so we are creating new cache entries and want to mimic what they would look like on-disk. Something within do_write_index() discovers that since CE_SKIP_WORKTREE is set, then also CE_EXTENDED should be set in order to ensure that the on-disk representation has enough room for the CE_SKIP_WORKTREE bit.

I suppose this might not have a meaningful purpose other than when I compare a full index against an expanded sparse-index and check if their flags match.

Thanks, -Stolee