Re: [PATCH v2 4/7] merge-ort: add a handle_deferred_entries() helper function
- From
Derrick Stolee <stolee@gmail.com>
- Date
- Jul 15, 2021, 14:32 UTC
- 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:
Show 12 quoted lines
> 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
Show 10 quoted lines
> +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