> Ah, true, "options->detect_rename" would be overly broad.
>
> I actually don't think it would be that bad to put the logic in
> diffcore_rename(). If we wait until the right moment (after inexact
> renames have been resolved, and when we see if there are any candidates
> left), it should just be a matter of walking over the candidate lists.
>
> Something like this (it would need the add_if_missing() helper from
> diffcore_std()):
[snip]
> @@ -538,6 +539,25 @@ void diffcore_rename(struct diff_options *options)
> break;
> }
>
> + /*
> + * At this point we know there's actual work to do: we have rename
> + * destinations that didn't find an exact match, and we have potential
> + * sources. So we'll have to do inexact rename detection, which
> + * requires looking at the blobs. It's worth pre-fetching them as a
> + * group now.
> + */
> + for (i = 0; i < rename_dst_nr; i++) {
> + if (rename_dst[i].pair)
> + continue; /* already found exact match */
> + add_if_missing(options->repo, &to_fetch, rename_dst[i].two);
> + }
> + for (i = 0; i < rename_src_nr; i++) {
> + add_if_missing(options->repo, &to_fetch, rename_src[i].p->one);
> + }
> + if (to_fetch.nr)
> + promisor_remote_get_direct(options->repo,
> + to_fetch.oid, to_fetch.nr);
> +
> if (options->show_rename_progress) {
> progress = start_delayed_progress(
> _("Performing inexact rename detection"),
And also the equivalent code in diffcore_break() and in diffcore_std()
after both these functions are invoked (in case nothing got prefetched,
but the diff still requires blobs).
