[PATCH v3 6/6] merge-recursive: add pointer about unduly complex looking code
- From
Elijah Newren <newren@gmail.com>
- Date
- Jun 10, 2018, 04:16 UTC
- Message-ID
- <20180610041616.4448-7-newren@gmail.com>
- In-Reply-To
- <20180610041616.4448-1-newren@gmail.com>
handle_change_delete() has a block of code displaying one of four nearly identical messages. Each contains about half a dozen variable interpolations, which use nearly identical variables as well. Someone trying to parse this may be slowed down trying to parse the differences and why they are here; help them out by adding a comment explaining the differences.
Further, point out that this code structure isn't collapsed into something more concise and readable for the programmer, because we want to keep full messages intact in order to make translators' jobs much easier.
Signed-off-by: Elijah Newren <newren@gmail.com> --- merge-recursive.c | 15 +++++++++++++++ 1 file changed, 15 insertions(+)
diff --git a/merge-recursive.c b/merge-recursive.c index 7cf11dc04c..284b27d895 100644 --- a/merge-recursive.c +++ b/merge-recursive.c @@ -1476,6 +1476,21 @@ static int handle_change_delete(struct merge_options *o, if (!ret) ret = update_file(o, 0, o_oid, o_mode, update_path); } else { + /* + * Despite the four nearly duplicate messages and argument + * lists below and the ugliness of the nested if-statements, + * having complete messages makes the job easier for + * translators. + * + * The slight variance among the cases is due to the fact + * that: + * 1) directory/file conflicts (in effect if + * !alt_path) could cause us to need to write the + * file to a different path. + * 2) renames (in effect if !old_path) could mean that + * there are two names for the path that the user + * may know the file by. + */ if (!alt_path) { if (!old_path) { output(o, 1, _("CONFLICT (%s/delete): %s deleted in %s "
-- 2.18.0.rc1.6.gffeb3ef585