From: Elijah Newren <newren@gmail.com>
To: git@vger.kernel.org
Cc: Elijah Newren <newren@gmail.com>
Subject: [PATCH 4/5] merge-recursive: rename conflict_rename_*() family of functions
Date: Fri, 18 May 2018 19:06:59 -0700 [thread overview]
Message-ID: <20180519020700.2241-5-newren@gmail.com> (raw)
In-Reply-To: <20180519020700.2241-1-newren@gmail.com>
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>
---
merge-recursive.c | 86 +++++++++++++++++++++++------------------------
1 file changed, 43 insertions(+), 43 deletions(-)
diff --git a/merge-recursive.c b/merge-recursive.c
index d30085d9c7..273ee79afa 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -1224,10 +1224,10 @@ static int merge_file_one(struct merge_options *o,
return merge_file_1(o, &one, &a, &b, path, branch1, branch2, mfi);
}
-static int conflict_rename_via_dir(struct merge_options *o,
- struct diff_filepair *pair,
- const char *rename_branch,
- const char *other_branch)
+static int handle_rename_via_dir(struct merge_options *o,
+ struct diff_filepair *pair,
+ const char *rename_branch,
+ const char *other_branch)
{
/*
* Handle file adds that need to be renamed due to directory rename
@@ -1329,10 +1329,10 @@ static int handle_change_delete(struct merge_options *o,
return ret;
}
-static int conflict_rename_delete(struct merge_options *o,
- struct diff_filepair *pair,
- const char *rename_branch,
- const char *delete_branch)
+static int handle_rename_delete(struct merge_options *o,
+ struct diff_filepair *pair,
+ const char *rename_branch,
+ const char *delete_branch)
{
const struct diff_filespec *orig = pair->one;
const struct diff_filespec *dest = pair->two;
@@ -1434,8 +1434,8 @@ static int handle_file(struct merge_options *o,
return ret;
}
-static int conflict_rename_rename_1to2(struct merge_options *o,
- struct rename_conflict_info *ci)
+static int handle_rename_rename_1to2(struct merge_options *o,
+ struct rename_conflict_info *ci)
{
/* One file was renamed in both branches, but to different names. */
struct diff_filespec *one = ci->pair1->one;
@@ -1496,8 +1496,8 @@ static int conflict_rename_rename_1to2(struct merge_options *o,
return 0;
}
-static int conflict_rename_rename_2to1(struct merge_options *o,
- struct rename_conflict_info *ci)
+static int handle_rename_rename_2to1(struct merge_options *o,
+ struct rename_conflict_info *ci)
{
/* Two files, a & b, were renamed to the same thing, c. */
struct diff_filespec *a = ci->pair1->one;
@@ -2231,7 +2231,7 @@ static void apply_directory_rename_modifications(struct merge_options *o,
* "NOTE" in update_stages(), doing so will modify the current
* in-memory index which will break calls to would_lose_untracked()
* that we need to make. Instead, we need to just make sure that
- * the various conflict_rename_*() functions update the index
+ * the various handle_rename_*() functions update the index
* explicitly rather than relying on unpack_trees() to have done it.
*/
get_tree_entry(&tree->object.oid,
@@ -2635,12 +2635,12 @@ static void initial_cleanup_rename(struct diff_queue_struct *pairs,
free(pairs);
}
-static int handle_renames(struct merge_options *o,
- struct tree *common,
- struct tree *head,
- struct tree *merge,
- struct string_list *entries,
- struct rename_info *ri)
+static int detect_and_process_renames(struct merge_options *o,
+ struct tree *common,
+ struct tree *head,
+ struct tree *merge,
+ struct string_list *entries,
+ struct rename_info *ri)
{
struct diff_queue_struct *head_pairs, *merge_pairs;
struct hashmap *dir_re_head, *dir_re_merge;
@@ -2911,12 +2911,12 @@ static int merge_content(struct merge_options *o,
return !is_dirty && mfi.clean;
}
-static int conflict_rename_normal(struct merge_options *o,
- const char *path,
- struct object_id *o_oid, unsigned int o_mode,
- struct object_id *a_oid, unsigned int a_mode,
- struct object_id *b_oid, unsigned int b_mode,
- struct rename_conflict_info *ci)
+static int handle_rename_normal(struct merge_options *o,
+ const char *path,
+ struct object_id *o_oid, unsigned int o_mode,
+ struct object_id *a_oid, unsigned int a_mode,
+ struct object_id *b_oid, unsigned int b_mode,
+ struct rename_conflict_info *ci)
{
/* Merge the content and write it out */
return merge_content(o, path, was_dirty(o, path),
@@ -2943,37 +2943,37 @@ static int process_entry(struct merge_options *o,
switch (conflict_info->rename_type) {
case RENAME_NORMAL:
case RENAME_ONE_FILE_TO_ONE:
- clean_merge = conflict_rename_normal(o,
- path,
- o_oid, o_mode,
- a_oid, a_mode,
- b_oid, b_mode,
- conflict_info);
+ clean_merge = handle_rename_normal(o,
+ path,
+ o_oid, o_mode,
+ a_oid, a_mode,
+ b_oid, b_mode,
+ conflict_info);
break;
case RENAME_VIA_DIR:
clean_merge = 1;
- if (conflict_rename_via_dir(o,
- conflict_info->pair1,
- conflict_info->branch1,
- conflict_info->branch2))
+ if (handle_rename_via_dir(o,
+ conflict_info->pair1,
+ conflict_info->branch1,
+ conflict_info->branch2))
clean_merge = -1;
break;
case RENAME_DELETE:
clean_merge = 0;
- if (conflict_rename_delete(o,
- conflict_info->pair1,
- conflict_info->branch1,
- conflict_info->branch2))
+ if (handle_rename_delete(o,
+ conflict_info->pair1,
+ conflict_info->branch1,
+ conflict_info->branch2))
clean_merge = -1;
break;
case RENAME_ONE_FILE_TO_TWO:
clean_merge = 0;
- if (conflict_rename_rename_1to2(o, conflict_info))
+ if (handle_rename_rename_1to2(o, conflict_info))
clean_merge = -1;
break;
case RENAME_TWO_FILES_TO_ONE:
clean_merge = 0;
- if (conflict_rename_rename_2to1(o, conflict_info))
+ if (handle_rename_rename_2to1(o, conflict_info))
clean_merge = -1;
break;
default:
@@ -3112,8 +3112,8 @@ int merge_trees(struct merge_options *o,
get_files_dirs(o, merge);
entries = get_unmerged();
- clean = handle_renames(o, common, head, merge, entries,
- &re_info);
+ clean = detect_and_process_renames(o, common, head, merge,
+ entries, &re_info);
record_df_conflict_files(o, entries);
if (clean < 0)
goto cleanup;
--
2.17.0.847.g20b8963732
next prev parent reply other threads:[~2018-05-19 2:07 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-19 2:06 [PATCH 0/5] merge-recursive code cleanups Elijah Newren
2018-05-19 2:06 ` [PATCH 1/5] merge-recursive: fix miscellaneous grammar error in comment Elijah Newren
2018-05-19 2:06 ` [PATCH 2/5] merge-recursive: fix numerous argument alignment issues Elijah Newren
2018-05-21 13:42 ` Johannes Schindelin
2018-05-21 16:48 ` Elijah Newren
2018-05-19 2:06 ` [PATCH 3/5] merge-recursive: clarify the rename_dir/RENAME_DIR meaning Elijah Newren
2018-05-21 14:28 ` Johannes Schindelin
2018-05-19 2:06 ` Elijah Newren [this message]
2018-05-21 14:30 ` [PATCH 4/5] merge-recursive: rename conflict_rename_*() family of functions Johannes Schindelin
2018-05-19 2:07 ` [PATCH 5/5] merge-recursive: simplify handle_change_delete Elijah Newren
2018-05-19 7:32 ` Johannes Sixt
2018-05-19 15:39 ` Elijah Newren
2018-05-21 13:41 ` Johannes Schindelin
2018-05-21 17:22 ` Elijah Newren
2018-05-22 0:43 ` [PATCH v2 0/5] merge-recursive code cleanups Elijah Newren
2018-05-22 0:43 ` [PATCH v2 1/5] merge-recursive: fix miscellaneous grammar error in comment Elijah Newren
2018-05-22 0:43 ` [PATCH v2 2/5] merge-recursive: fix numerous argument alignment issues Elijah Newren
2018-05-22 0:43 ` [PATCH v2 3/5] merge-recursive: clarify the rename_dir/RENAME_DIR meaning Elijah Newren
2018-05-22 0:43 ` [PATCH v2 4/5] merge-recursive: rename conflict_rename_*() family of functions Elijah Newren
2018-05-22 0:43 ` [PATCH v2 5/5] merge-recursive: add pointer about unduly complex looking code Elijah Newren
2018-06-10 4:16 ` [PATCH v3 0/6] merge-recursive code cleanups Elijah Newren
2018-06-10 4:16 ` [PATCH v3 1/6] merge-recursive: fix miscellaneous grammar error in comment Elijah Newren
2018-06-10 4:16 ` [PATCH v3 2/6] merge-recursive: fix numerous argument alignment issues Elijah Newren
2018-06-10 4:16 ` [PATCH v3 3/6] merge-recursive: align labels with their respective code blocks Elijah Newren
2018-06-10 4:16 ` [PATCH v3 4/6] merge-recursive: clarify the rename_dir/RENAME_DIR meaning Elijah Newren
2018-06-10 4:16 ` [PATCH v3 5/6] merge-recursive: rename conflict_rename_*() family of functions Elijah Newren
2018-06-10 4:16 ` [PATCH v3 6/6] merge-recursive: add pointer about unduly complex looking code Elijah Newren
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180519020700.2241-5-newren@gmail.com \
--to=newren@gmail.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.