On Wed, Oct 31, 2018 at 6:57 AM Derrick Stolee <sto...@gmail.com> wrote: > > On 10/31/2018 9:53 AM, Derrick Stolee wrote: > > On 10/19/2018 3:31 PM, Elijah Newren wrote: > >> +#if 0 // #if-0-ing avoids unused function warning; will make live in > >> next commit > >> +static int handle_file_collision(struct merge_options *o, > >> + const char *collide_path, > >> + const char *prev_path1, > >> + const char *prev_path2, > >> + const char *branch1, const char *branch2, > >> + const struct object_id *a_oid, > >> + unsigned int a_mode, > >> + const struct object_id *b_oid, > >> + unsigned int b_mode) > >> +{ > >> + struct merge_file_info mfi; > >> + struct diff_filespec null, a, b; > >> + char *alt_path = NULL; > >> + const char *update_path = collide_path; > >> + > >> + /* > >> + * In the recursive case, we just opt to undo renames > >> + */ > >> + if (o->call_depth && (prev_path1 || prev_path2)) { > >> + /* Put first file (a_oid, a_mode) in its original spot */ > >> + if (prev_path1) { > >> + if (update_file(o, 1, a_oid, a_mode, prev_path1)) > >> + return -1; > >> + } else { > >> + if (update_file(o, 1, a_oid, a_mode, collide_path)) > > > > The latest test coverage report [1] shows this if statement is never > > run, so > > it appears that every call to this method in the test suite has either > > o->call_depth positive, prev_path1 non-NULL, or both prev_path1 and > > prev_path2 > > NULL. > > > > Is there a way we can add a test case that calls this method with > > o->call_depth > > positive, prev_path1 NULL, and prev_path2 non-NULL? > > > >> + return -1; > >> + } > >> + > >> + /* Put second file (b_oid, b_mode) in its original spot */ > >> + if (prev_path2) { > >> + if (update_file(o, 1, b_oid, b_mode, prev_path2)) > > > > Since this line is covered, we _do_ call the method with prev_path2 > > non-NULL, but > > prev_path1 must be non-NULL in all cases. > > > > I may have found a reason why this doesn't happen in one of the > > callers you introduced. > > I'm going to comment on PATCH 8/8 to see if that is the case. > > Nevermind on the PATCH 8/8 situation. I thought I saw you pass (a->path, > NULL) and > (b->path, NULL) into the (prev_path1, prev_path2) pairs, but in each > case the non-NULL > parameter is actually for 'collide_path'. > > It is still interesting if we can hit this case. Perhaps we need a > different kind of > conflict, like (rename, delete) [but I struggle to make sense of how to > do that].
rename/delete conflicts are sent through handle_rename_delete() which do not call into handle_file_collision(). What you'd instead need is a rename/add conflict, in the virtual merge base, on the appropriate side. The fact that the prev_path2 non-NULL case is covered means there's already a regression test that's probably nearly good enough, you'd just need to edit the committer timestamps of the two merge bases so that a different one was older. I'm pretty sure we can come up with one without too much effort. I'll take a look tomorrow; too late tonight.