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

On 3/23/2021 4:10 PM, Junio C Hamano wrote:

Derrick Stolee [off-list ref] writes:

quoted

quoted

quoted

+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.

quoted

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