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
List information: http://vger.kernel.org/majordomo-info.html
* 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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).