Re: [PATCH v2 06/13] merge-ort: add data structures for in-memory caching of rename detection

On 5/17/2021 11:55 PM, Elijah Newren wrote:

quoted

        /*
         * cached_irrelevant: Caching of rename_sources that aren't relevant.
         *
         * cached_pairs records both renames and deletes.  Sometimes we
         * do not know if a path is a rename or a delete because we pass
         * RELEVANT_LOCATION to diffcore_rename_extended() which might
         * describe a path as "irrelevant" instead of as a "rename" or "delete".
         *  We need to cache such paths too, but separately from cached_pairs.
         */

Does this make sense? diffcore_rename_extended() might need an update
to match this extra, explicit state.

Hmm, let's flesh out the description a bit and try to be more
explicit.  How about:

    /*
     * cached_irrelevant: Caching of rename_sources that aren't relevant.
     *
     * If we try to detect a rename for a source path and succeed, it's
     * part of a rename.  If we try to detect a rename for a source path
     * and fail, then it's a delete.  If we do not try to detect a rename
     * for a path, then we don't know if it's a rename or a delete.  If
     * merge-ort doesn't think the path is relevant, then we just won't
     * cache anything for that path.  But there's a slight problem in
     * that merge-ort can think a path is RELEVANT_LOCATION, but due to
     * commit 9bd342137e ("diffcore-rename: determine which
     * relevant_sources are no longer relevant", 2021-03-13),
     * diffcore-rename can downgrade the path to RELEVANT_NO_MORE.  To
     * avoid excessive calls to diffcore_rename_extended() we still need
     * to cache such paths, though we cannot record them as either
     * renames or deletes.  So we cache them here as a "turned out to be
     * irrelevant *for this commit*" as they are often also irrelevant
     * for subsequent commits, though we will have to do some extra
     * checking to see whether such paths become relevant for rename
     * detection when cherry-picking/rebasing subsequent commits.
     */

This is more informative, thanks.
-Stolee