Hi Derrick, Thanks for taking a look, and apologies for the delayed response. On 15/08/2024 10:25, Derrick Stolee wrote: > The key issue with this reproducer is the following: the sparse index > config is set in the worktree config. When you are running this move > command from the main-worktree, it is not configured to work with a > sparse index. Thus, when reading the index, Git thinks the sparse > index is disabled and must inflate the index into a full one before > continuing. > > For full information, this happens in the callstack > > move_worktree() > validate_no_submodules() > read_index_from() > do_read_index() > ensure_correct_sparsity() > ensure_full_index() > > If you add "git -C main-worktree sparse-checkout set A --sparse-index" > before you create the other-worktree (or move it) then the message > does not appear. > > This is a quirk of the worktree config that may be worth updating to > respect the sparse index of the target worktree, but may also be worth > leaving as-is because we are running this from a different worktree. It seems to me that we really should be respecting the sparsity of the worktree being moved rather than the worktree from which we happened to run the command, at least in this case. The purpose of reading the index (in this call stack) is to ensure that there are no submodules in the worktree being moved, so the index of (and therefore, the sparse-index config of) the worktree from which the command is running seems irrelevant. I poked at this a little bit, and the main challenge seems to be that `is_sparse_index_allowed()` uses some cached `core_apply_sparse_checkout` and `core_sparse_checkout_cone` values that are populated with the config from the worktree in which the command is being run, rather than accepting those values directly or via some worktree object. It looks like this would need some fairly significant refactoring to address since there are multiple functions in that call chain that would need to be updated to allow passing something more worktree-specific through, and those functions (most notably `read_index_from()` are called from several places. -- Thank you, Brian Lyles
