"Derrick Stolee via GitGitGadget" [off-list ref] writes:
This RFC proposes an update to the index formats to allow "sparse directory
entries". These entries correspond to directories that are completely
excluded from the sparse checkout definition. We can detect that a directory
is excluded when using "cone mode" patterns.
Yay.
Since having directory entries is a radical departure from the existing
index format, a new extension "extensions.sparseIndex" is added. Using a
sparse index should cause incompatible tools to fail because they do not
understand this extension.
Safety is good, but because the index is purely a local matter, we
do not have to be so careful as updating the network protocols or
pack/object formats.
I think the use of "extensions.*" mechanism to render the repository
that uses the new feature unusable by older Git is safe enough, but
it may be too draconian. For example, when things go wrong, don't
you want to "fetch"/"clone" from it into another repository to first
save the objects and refs? You do not need a version of the index
file you understand in order to do that.
The index format has a mechanism to make older versions of Git bail
when it encounters a file that uses newer feature that they do not
understand. Perhaps using it is sufficient instead?
On 1/25/21 3:10 PM, Junio C Hamano wrote:
"Derrick Stolee via GitGitGadget" [off-list ref] writes:
quoted
This RFC proposes an update to the index formats to allow "sparse directory
entries". These entries correspond to directories that are completely
excluded from the sparse checkout definition. We can detect that a directory
is excluded when using "cone mode" patterns.
Yay.
quoted
Since having directory entries is a radical departure from the existing
index format, a new extension "extensions.sparseIndex" is added. Using a
sparse index should cause incompatible tools to fail because they do not
understand this extension.
Safety is good, but because the index is purely a local matter, we
do not have to be so careful as updating the network protocols or
pack/object formats.
I think the use of "extensions.*" mechanism to render the repository
that uses the new feature unusable by older Git is safe enough, but
it may be too draconian. For example, when things go wrong, don't
you want to "fetch"/"clone" from it into another repository to first
save the objects and refs? You do not need a version of the index
file you understand in order to do that.
The index format has a mechanism to make older versions of Git bail
when it encounters a file that uses newer feature that they do not
understand. Perhaps using it is sufficient instead?
There are interesting subtleties with the differences between index
formats 2, 3, and 4 that are worth keeping around. Perhaps the
extension could be a mechanism for allowing sparse directories in
those versions, but then a future "index version 5" includes sparse
directories without the extension.
I could spend time working on such an index v5 in parallel with
the updates to Git commands to make them sparse aware. The logic
from patches 1-14 in this series will be required before that could
begin.
Thanks,
-Stolee