Message ID | fb4c7038b7468c77c4d3c5181f0cb0de85d1149f.1615929436.git.gitgitgadget@gmail.com (mailing list archive) |
---|---|
State | Superseded |
Headers | show |
Series | Sparse Index: API protections | expand |
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. > Signed-off-by: Derrick Stolee <dstolee@microsoft.com> > --- > merge-ort.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/merge-ort.c b/merge-ort.c > index 603d30c52170..9f737212555d 100644 > --- a/merge-ort.c > +++ b/merge-ort.c > @@ -3112,6 +3112,7 @@ static int record_conflicted_index_entries(struct merge_options *opt, > if (strmap_empty(conflicted)) > return 0; > > + ensure_full_index(index); > original_cache_nr = index->cache_nr; > > /* Put every entry from paths into plist, then sort */ > -- > gitgitgadget
On 3/18/2021 1:31 AM, Elijah Newren wrote: > 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
diff --git a/merge-ort.c b/merge-ort.c index 603d30c52170..9f737212555d 100644 --- a/merge-ort.c +++ b/merge-ort.c @@ -3112,6 +3112,7 @@ static int record_conflicted_index_entries(struct merge_options *opt, if (strmap_empty(conflicted)) return 0; + ensure_full_index(index); original_cache_nr = index->cache_nr; /* Put every entry from paths into plist, then sort */