Re: [PATCH v3 01/20] sparse-index: design doc and format update

> Derrick Stolee <stolee@gmail.com> writes:
> 
>>>> +Three important scale dimensions for a Git worktree are:
>>>
>>> s/worktree/working tree/; The former is the thing the "git worktree"
>>> command deals with.  The latter is relevant even when "git worktree"
>>> is not used (the traditional "git clone and you get a working tree
>>> to work in").
>>
>> I guess I'm distracted by using SKIP_WORKTREE a lot, but "working
>> directory" is more specific and hence better.
> 
> Since the user's current working directory can be outside any
> working tree that is governed by any git repository, "working
> directory" is a term I try to avoid when describing the directory
> where a checkout of a revision lives.
> 
> Documentation/glossary-content.txt is where the suggestion for
> "working tree" comes from.

>> I meant by "serialized index file" is that the file written to disk has
>> the sparse directory entries, but the in-core copy will not (except for
>> a very brief moment in time, during do_read_index()).
> 
> Nice.  That would probably mean cache-tree extension on-disk can go
> away, because we can populate in-core cache-tree from these entries.
> I've always hated the on-disk encoding of that extension.
> 
> Or we are not doing this "extra tree" everywhere (i.e. limited only
> to the parts that are marked for "sparse checkout")?