git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Elijah Newren <newren@gmail.com>
To: gitster@pobox.com
Cc: git@vger.kernel.org, Johannes.Schindelin@gmx.de,
	Elijah Newren <newren@gmail.com>
Subject: [PATCH v3 6/6] merge-recursive: add pointer about unduly complex looking code
Date: Sat,  9 Jun 2018 21:16:16 -0700	[thread overview]
Message-ID: <20180610041616.4448-7-newren@gmail.com> (raw)
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


      parent reply	other threads:[~2018-06-10  4:16 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 ` [PATCH 4/5] merge-recursive: rename conflict_rename_*() family of functions Elijah Newren
2018-05-21 14:30   ` 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     ` Elijah Newren [this message]

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=20180610041616.4448-7-newren@gmail.com \
    --to=newren@gmail.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /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 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 NNTP newsgroup(s).