Re: [PATCH v3 4/8] merge-recursive: new function for better colliding conflict resolutions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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].

Thanks,
-Stolee




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux