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 0/6] merge-recursive code cleanups
Date: Sat,  9 Jun 2018 21:16:10 -0700	[thread overview]
Message-ID: <20180610041616.4448-1-newren@gmail.com> (raw)
In-Reply-To: <20180522004327.13085-1-newren@gmail.com>

This patch series contains several small code cleanups for
merge-recursive.

Changes since v2:
  * Now built on master (the topics this depended on have graduated);
    merges cleanly with next and pu.
  * Patch #2 has a few additional argument alignment fixes; some in
    code added by topics that have since graduated, and a couple that
    were overlooked previously.
  * Patch #3 is entirely new.
  * Re-wrapped the commit message of the final patch.
  (range-diff below)

Elijah Newren (6):
  merge-recursive: fix miscellaneous grammar error in comment
  merge-recursive: fix numerous argument alignment issues
  merge-recursive: align labels with their respective code blocks
  merge-recursive: clarify the rename_dir/RENAME_DIR meaning
  merge-recursive: rename conflict_rename_*() family of functions
  merge-recursive: add pointer about unduly complex looking code

 merge-recursive.c | 186 ++++++++++++++++++++++++++--------------------
 1 file changed, 104 insertions(+), 82 deletions(-)

range-diff against v2:

 1: 4222f174de =  1: 4222f174de merge-recursive: fix miscellaneous grammar error in comment
 2: 4ebf93822d !  2: 284a5fee3d merge-recursive: fix numerous argument alignment issues
    @@ -33,6 +33,76 @@
      {
      	struct path_hashmap_entry *entry;
      	int baselen = base->len;
    +@@
    + 	 */
    + 	if (would_lose_untracked(path))
    + 		return err(o, _("refusing to lose untracked file at '%s'"),
    +-			     path);
    ++			   path);
    + 
    + 	/* Successful unlink is good.. */
    + 	if (!unlink(path))
    +@@
    + 			unlink(path);
    + 			if (symlink(lnk, path))
    + 				ret = err(o, _("failed to symlink '%s': %s"),
    +-					path, strerror(errno));
    ++					  path, strerror(errno));
    + 			free(lnk);
    + 		} else
    + 			ret = err(o,
    +@@
    + }
    + 
    + static int find_first_merges(struct object_array *result, const char *path,
    +-		struct commit *a, struct commit *b)
    ++			     struct commit *a, struct commit *b)
    + {
    + 	int i, j;
    + 	struct object_array merges = OBJECT_ARRAY_INIT;
    +@@
    + 
    + 	/* get all revisions that merge commit a */
    + 	xsnprintf(merged_revision, sizeof(merged_revision), "^%s",
    +-			oid_to_hex(&a->object.oid));
    ++		  oid_to_hex(&a->object.oid));
    + 	init_revisions(&revs, NULL);
    + 	rev_opts.submodule = path;
    + 	/* FIXME: can't handle linked worktrees in submodules yet */
    +@@
    + 		output(o, 2, _("Found a possible merge resolution for the submodule:\n"));
    + 		print_commit((struct commit *) merges.objects[0].item);
    + 		output(o, 2, _(
    +-			"If this is correct simply add it to the index "
    +-			"for example\n"
    +-			"by using:\n\n"
    +-			"  git update-index --cacheinfo 160000 %s \"%s\"\n\n"
    +-			"which will accept this suggestion.\n"),
    +-			oid_to_hex(&merges.objects[0].item->oid), path);
    ++		       "If this is correct simply add it to the index "
    ++		       "for example\n"
    ++		       "by using:\n\n"
    ++		       "  git update-index --cacheinfo 160000 %s \"%s\"\n\n"
    ++		       "which will accept this suggestion.\n"),
    ++		       oid_to_hex(&merges.objects[0].item->oid), path);
    + 		break;
    + 
    + 	default:
    +@@
    + 			result->clean = (merge_status == 0);
    + 		} else if (S_ISGITLINK(a->mode)) {
    + 			result->clean = merge_submodule(o, &result->oid,
    +-						       one->path,
    +-						       &one->oid,
    +-						       &a->oid,
    +-						       &b->oid);
    ++							one->path,
    ++							&one->oid,
    ++							&a->oid,
    ++							&b->oid);
    + 		} else if (S_ISLNK(a->mode)) {
    + 			switch (o->recursive_variant) {
    + 			case MERGE_RECURSIVE_NORMAL:
     @@
      }
      
--: ---------- >  3: 6bae2a267f merge-recursive: align labels with their respective code blocks
 3: 585759f07a =  4: aecf1267d8 merge-recursive: clarify the rename_dir/RENAME_DIR meaning
 4: 3cfb8b01b8 =  5: f7637bef12 merge-recursive: rename conflict_rename_*() family of functions
 5: d2a24f5b38 !  6: ffeb3ef585 merge-recursive: add pointer about unduly complex looking code
    @@ -3,10 +3,11 @@
         merge-recursive: add pointer about unduly complex looking code
     
         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.
    +    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


-- 
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   ` Elijah Newren [this message]
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=20180610041616.4448-1-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).