On 3/23/2021 4:10 PM, Junio C Hamano wrote: > Derrick Stolee <stolee@xxxxxxxxx> 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
