From: Derrick Stolee Date: Tue, 23 Mar 2021 20:42:52 GMT Subject: Re: [PATCH v3 01/20] sparse-index: design doc and format update Message-ID: <7cb99ad8-3853-5670-6b9f-7b4afe3603a2@gmail.com> In-Reply-To: On 3/23/2021 4:10 PM, Junio C Hamano wrote: > Derrick Stolee 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. Whoops. Somehow I read that wrong. Thanks for pointing out my error. >> 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")? The current design is to only have these entries when all paths within the directory are marked with SKIP_WORKTREE. This pairs with the cache-tree extension, which has these directories as nodes, but only consuming one cache entry (for itself). I haven't considered the idea of inserting trees for other reasons. Seems like a valuable experiment. Thanks, -Stolee