From: Jeff Hostetler Date: Thu, 23 Mar 2023 14:32:00 GMT Subject: Re: [PATCH 4/4] unpack-trees: take care to propagate the split-index flag Message-ID: <5a6e83e6-c14b-f2bb-5ec1-669ee7d246c8@jeffhostetler.com> In-Reply-To: <3963d3e542896b9cdf871dc7ea13330ddac87795.1679500859.git.gitgitgadget@gmail.com> On 3/22/23 12:00 PM, Johannes Schindelin via GitGitGadget wrote: > From: Johannes Schindelin > > When copying the `split_index` structure from one index structure to > another, we need to propagate the `SPLIT_INDEX_ORDERED` flag, too, if it > is set, otherwise Git might forget to write the shared index when that > is actually needed. > > It just so _happens_ that in many instances when `unpack_trees()` is > called, the result causes the shared index to be written anyway, but > there are edge cases when that is not so. > > Signed-off-by: Johannes Schindelin > --- > unpack-trees.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/unpack-trees.c b/unpack-trees.c > index 90b92114be8..ca5e47c77c0 100644 > --- a/unpack-trees.c > +++ b/unpack-trees.c > @@ -1916,6 +1916,8 @@ int unpack_trees(unsigned len, struct tree_desc *t, struct unpack_trees_options > * create a new one. > */ > o->result.split_index = o->src_index->split_index; > + if (o->src_index->cache_changed & SPLIT_INDEX_ORDERED) > + o->result.cache_changed |= SPLIT_INDEX_ORDERED; Nice find! > o->result.split_index->refcount++; > } else { > o->result.split_index = init_split_index(&o->result);