From: Derrick Stolee <stolee@gmail.com>
Date: Thu, 15 Jul 2021 14:32:05 GMT
Subject: Re: [PATCH v2 4/7] merge-ort: add a handle_deferred_entries() helper function
Message-ID: <4aa2f487-ad4b-b7fc-2ee0-b78c3703d955@gmail.com>
In-Reply-To: <7e28323b624ad2d8d12123783f00f5a8fbb248e8.1626204784.git.gitgitgadget@gmail.com>

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.

> +		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