Re: [PATCH 20/27] merge-ort: ensure full index
- From
Derrick Stolee <stolee@gmail.com>
- Date
- Mar 23, 2021, 13:26 UTC
- Message-ID
- <e445a124-4715-a304-a006-08c2d1ad86ad@gmail.com>
- In-Reply-To
- <CABPp-BF93UaU7JnwxQiEp2wf1jffLfQax+z4_8Q3-6DxXPUgRg@mail.gmail.com>
On 3/18/2021 1:31 AM, Elijah Newren wrote:
Show 24 quoted lines
> On Tue, Mar 16, 2021 at 2:17 PM Derrick Stolee via GitGitGadget > <gitgitgadget@gmail.com> wrote: >> >> From: Derrick Stolee <dstolee@microsoft.com> >> >> 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@gmail.com/ > > 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