Re: [PATCH v2 4/7] merge-ort: add a handle_deferred_entries() helper function

[Elijah Newren <newren@gmail.com>]

On Thu, Jul 15, 2021 at 7:32 AM Derrick Stolee <stolee@gmail.com> wrote:
>
> On 7/13/2021 3:33 PM, Elijah Newren via GitGitGadget wrote:
> > From: Elijah Newren <newren@gmail.com>
> >
> > 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