Re: [PATCH 4/5] merge-recursive: rename conflict_rename_*() family of functions

> These functions were added because processing of these conflicts needed
> to be deferred until process_entry() in order to get D/F conflicts and
> such right.  The number of these has grown over time, and now include
> some whose name is misleading:
>   * conflict_rename_normal() is for handling normal file renames; a
>     typical rename may need content merging, but we expect conflicts
>     from that to be more the exception than the rule.
>   * conflict_rename_via_dir() will not be a conflict; it was just an
>     add that turned into a move due to directory rename detection.
>     (If there was a file in the way of the move, that would have been
>     detected and reported earlier.)
>   * conflict_rename_rename_2to1 and conflict_rename_add (the latter
>     of which doesn't exist yet but has been submitted before and I
>     intend to resend) technically might not be conflicts if the
>     colliding paths happen to match exactly.
> Rename this family of functions to handle_rename_*().
> 
> Also rename handle_renames() to detect_and_process_renames() both to make
> it clearer what it does, and to differentiate it as a pre-processing step
> from all the handle_rename_*() functions which are called from
> process_entry().
> 
> Signed-off-by: Elijah Newren <newren@gmail.com>