Hi Elijah,
On Fri, 18 May 2018, Elijah Newren wrote: > 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 <new...@gmail.com> Makes sense, and the patch looks obviously correct to me. Thanks, Dscho
