On 3/18/2021 1:31 AM, Elijah Newren wrote: > On Tue, Mar 16, 2021 at 2:17 PM Derrick Stolee via GitGitGadget > <gitgitgadget@xxxxxxxxx> wrote: >> >> From: Derrick Stolee <dstolee@xxxxxxxxxxxxx> >> >> Before iterating over all cache entries, ensure that a sparse index is >> expanded to a full one to avoid unexpected behavior. >> >> This is a top candidate for updating later with a proper integration >> with the sparse index, since we will likely enable the ORT strategy by >> default when the sparse index is enabled. This appears to be the only > > s/appears to be/is/ :-) > >> place where the ORT strategy interacts with the index in such a global >> way, so that integration should be clear once the ORT strategy and the >> sparse index topics stabilize. > > Right, there is one more patch that will touch this function -- patch > 7 from the series that marks merge-ort stable over here: > https://lore.kernel.org/git/pull.905.v2.git.1616016485.gitgitgadget@xxxxxxxxx/ > > While I have more optimizations for merge-ort, none of them will touch > this function. Yes, I noticed that that was one of the conflicts introduced with this series. I took a closer look at that patch and method, and it seems like it only cares about paths with SKIP_WORKTREE _and_ is conflicted. If it has a conflict, then I believe we won't collapse those entries to a sparse-directory entry. I think I will drop this patch for now, and rely on the fact that I plan to enable merge-ORT directly if sparse-index is enabled. At that time, I will carefully test this logic. For now, the 'command_requires_full_index' guard will be sufficient to preserve behavior. Thanks, -Stolee
