Extract the body of a loop that attempts to replay recorded
resolution for each conflicted path into a helper function, not
because I want to call it from multiple places later, but because
the logic has become too deeply nested and hard to read.

Signed-off-by: Junio C Hamano <gits...@pobox.com>
---
 rerere.c | 75 ++++++++++++++++++++++++++++++++++------------------------------
 1 file changed, 40 insertions(+), 35 deletions(-)

diff --git a/rerere.c b/rerere.c
index 7ef951e..09b72ed 100644
--- a/rerere.c
+++ b/rerere.c
@@ -620,6 +620,44 @@ static void update_paths(struct string_list *update)
                rollback_lock_file(&index_lock);
 }
 
+/*
+ * The path indicated by rr_item may still have conflict for which we
+ * have a recorded resolution, in which case replay it and optionally
+ * update it.  Or it may have been resolved by the user and we may
+ * only have the preimage for that conflict, in which case the result
+ * needs to be recorded as a resolution in a postimage file.
+ */
+static void do_rerere_one_path(struct string_list_item *rr_item,
+                              struct string_list *update)
+{
+       const char *path = rr_item->string;
+       const char *name = (const char *)rr_item->util;
+
+       /* Is there a recorded resolution we could attempt to apply? */
+       if (has_rerere_resolution(name)) {
+               if (merge(name, path))
+                       return; /* failed to replay */
+
+               if (rerere_autoupdate)
+                       string_list_insert(update, path);
+               else
+                       fprintf(stderr,
+                               "Resolved '%s' using previous resolution.\n",
+                               path);
+               goto mark_resolved;
+       }
+
+       /* Let's see if the user has resolved it. */
+       if (handle_file(path, NULL, NULL))
+               return; /* not yet resolved */
+
+       copy_file(rerere_path(name, "postimage"), path, 0666);
+       fprintf(stderr, "Recorded resolution for '%s'.\n", path);
+mark_resolved:
+       free(rr_item->util);
+       rr_item->util = NULL;
+}
+
 static int do_plain_rerere(struct string_list *rr, int fd)
 {
        struct string_list conflict = STRING_LIST_INIT_DUP;
@@ -673,41 +711,8 @@ static int do_plain_rerere(struct string_list *rr, int fd)
                }
        }
 
-       /*
-        * Some of the paths that had conflicts earlier might have
-        * been resolved by the user.  Others may be similar to a
-        * conflict already that was resolved before.
-        */
-       for (i = 0; i < rr->nr; i++) {
-               int ret;
-               const char *path = rr->items[i].string;
-               const char *name = (const char *)rr->items[i].util;
-
-               /* Is there a recorded resolution we could attempt to apply? */
-               if (has_rerere_resolution(name)) {
-                       if (merge(name, path))
-                               continue;
-
-                       if (rerere_autoupdate)
-                               string_list_insert(&update, path);
-                       else
-                               fprintf(stderr,
-                                       "Resolved '%s' using previous 
resolution.\n",
-                                       path);
-                       goto mark_resolved;
-               }
-
-               /* Let's see if the user has resolved it. */
-               ret = handle_file(path, NULL, NULL);
-               if (ret)
-                       continue;
-
-               copy_file(rerere_path(name, "postimage"), path, 0666);
-               fprintf(stderr, "Recorded resolution for '%s'.\n", path);
-       mark_resolved:
-               free(rr->items[i].util);
-               rr->items[i].util = NULL;
-       }
+       for (i = 0; i < rr->nr; i++)
+               do_rerere_one_path(&rr->items[i], &update);
 
        if (update.nr)
                update_paths(&update);
-- 
2.5.0-rc2-340-g0cccc16

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to