On Thu, Jul 15, 2021 at 7:32 AM Derrick Stolee <stolee@xxxxxxxxx> wrote:
>
> On 7/13/2021 3:33 PM, Elijah Newren via GitGitGadget wrote:
> > From: Elijah Newren <newren@xxxxxxxxx>
> >
> > In order to allow trivial directory resolution, we first need to be able
> > to gather more information to determine if the optimization is safe. To
> > enable that, we need a way of deferring the recursion into the directory
> > until a later time. Naturally, deferring the entry into a subtree means
> > that we need some function that will later recurse into the subdirectory
> > exactly the same way that collect_merge_info_callback() would have done.
> >
> > Add a helper function that does this. For now this function is not used
> > but a subsequent commit will change that. Future commits will also make
> > the function sometimes resolve directories instead of traversing inside.
> ...> +MAYBE_UNUSED
> > +static int handle_deferred_entries(struct merge_options *opt,
> > + struct traverse_info *info)
> > +{
> > + struct rename_info *renames = &opt->priv->renames;
> > + struct hashmap_iter iter;
> > + struct strmap_entry *entry;
> > + int side, ret = 0;
> > +
> > + for (side = MERGE_SIDE1; side <= MERGE_SIDE2; side++) {
> > + renames->trivial_merges_okay[side] = 0;
>
> We are unconditionally setting this to zero? I will await the
> use of the method to see how that affects things.
Unconditionally set to 0 because at this point in the series we don't
yet have the logic to handle it. This line will be replaced later
once we add the necessary logic.
>
> > + strintmap_for_each_entry(&renames->possible_trivial_merges[side],
> > + &iter, entry) {
>
> The rest of this loop seems like standard logic for handling
> these tree walks.
>
> Thanks,
> -Stolee
