Git Mailing List Archive mirror
 help / color / mirror / Atom feed
* [PATCH] update-index: do not read HEAD and MERGE_HEAD unconditionally
@ 2023-07-27 19:24 Junio C Hamano
  0 siblings, 0 replies; only message in thread
From: Junio C Hamano @ 2023-07-27 19:24 UTC (permalink / raw
  To: git

When "update-index --unresolve $path" cannot find the resolve-undo
record for the path the user requested to unresolve, it stuffs the
blobs from HEAD and MERGE_HEAD to stage #2 and stage #3 as a
fallback.  For this reason, the operation does not even start unless
both "HEAD" and "MERGE_HEAD" exist.

This is suboptimal in a few ways:

 * It does not recreate stage #1.  Even though it is a correct
   design decision not to do so (because it is impossible to
   recreate in general cases, without knowing how we got there,
   including what merge strategy was used), it is much less useful
   not to have that information in the index.

 * It limits the "unresolve" operation only during a conflicted "git
   merge" and nothing else.  Other operations like "rebase",
   "cherry-pick", and "switch -m" may result in conflicts, and the
   user may want to unresolve the conflict that they incorrectly
   resolved in order to redo the resolution, but the fallback would
   not kick in.

 * Most importantly, the entire "unresolve" operation is disabled
   after a conflicted merge is committed and MERGE_HEAD is removed,
   even though the index has perfectly usable resolve-undo records.

By lazily reading the HEAD and MERGE_HEAD only when we need to go to
the fallback codepath, we will allow cases where resolve-undo
records are available (which is 100% of the time, unless the user is
reading from an index file created by Git more than 10 years ago) to
proceed even after a conflicted merge was committed, during other
mergy operations that do not use MERGE_HEAD, or after the result of
such mergy operations has been committed.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 * Once the codepath starts using resolve-undo data for recovering
   from "resolved to removal", I think we can fully remove this
   fallback codepath.  But we'd need to first move away from the
   unmerge_index_entry_at() that assumes that the path to be
   unresolved must be in the index.  That should happen in future
   patches.

 builtin/update-index.c    | 46 ++++++++++++++++++++++++---------------
 t/t2030-unresolve-info.sh |  8 +++++++
 2 files changed, 36 insertions(+), 18 deletions(-)

diff --git a/builtin/update-index.c b/builtin/update-index.c
index aee3cb8cbd..853ec9eb7a 100644
--- a/builtin/update-index.c
+++ b/builtin/update-index.c
@@ -640,6 +640,21 @@ static struct cache_entry *read_one_ent(const char *which,
 	return ce;
 }
 
+static int read_head_pointers(void)
+{
+	static int result = -2; /* unknown yet */
+
+	if (result == -2) {
+		result = -1;
+		if (read_ref("HEAD", &head_oid))
+			return error("No HEAD -- no initial comit yet?");
+		if (read_ref("MERGE_HEAD", &merge_head_oid))
+			return error("Not in the middle of a merge");
+		result = 0;
+	}
+	return result;
+}
+
 static int unresolve_one(const char *path)
 {
 	int namelen = strlen(path);
@@ -678,10 +693,20 @@ static int unresolve_one(const char *path)
 		}
 	}
 
-	/* Grab blobs from given path from HEAD and MERGE_HEAD,
-	 * stuff HEAD version in stage #2,
-	 * stuff MERGE_HEAD version in stage #3.
+	/*
+	 * We are not using resolve-undo information but just
+	 * populating the stages #2 and #3 from HEAD and MERGE_HEAD.
+	 *
+	 * This is a flawed replacement of true "unresolve", as we do
+	 * not have a way to recreate the stage #1 for the common
+	 * ancestor (which may not be a unique merge-base between the
+	 * two).
 	 */
+	if (read_head_pointers()) {
+		ret = -1;
+		goto free_return;
+	}
+
 	ce_2 = read_one_ent("our", &head_oid, path, namelen, 2);
 	ce_3 = read_one_ent("their", &merge_head_oid, path, namelen, 3);
 
@@ -712,27 +737,12 @@ static int unresolve_one(const char *path)
 	return ret;
 }
 
-static void read_head_pointers(void)
-{
-	if (read_ref("HEAD", &head_oid))
-		die("No HEAD -- no initial commit yet?");
-	if (read_ref("MERGE_HEAD", &merge_head_oid)) {
-		fprintf(stderr, "Not in the middle of a merge.\n");
-		exit(0);
-	}
-}
-
 static int do_unresolve(int ac, const char **av,
 			const char *prefix, int prefix_length)
 {
 	int i;
 	int err = 0;
 
-	/* Read HEAD and MERGE_HEAD; if MERGE_HEAD does not exist, we
-	 * are not doing a merge, so exit with success status.
-	 */
-	read_head_pointers();
-
 	for (i = 1; i < ac; i++) {
 		const char *arg = av[i];
 		char *p = prefix_path(prefix, prefix_length, arg);
diff --git a/t/t2030-unresolve-info.sh b/t/t2030-unresolve-info.sh
index 2d8c70b03a..d4e7760df5 100755
--- a/t/t2030-unresolve-info.sh
+++ b/t/t2030-unresolve-info.sh
@@ -126,6 +126,14 @@ test_expect_success 'unmerge with plumbing' '
 	test_line_count = 3 actual
 '
 
+test_expect_success 'unmerge can be done even after committing' '
+	prime_resolve_undo &&
+	git commit -m "record to nuke MERGE_HEAD" &&
+	git update-index --unresolve fi/le &&
+	git ls-files -u >actual &&
+	test_line_count = 3 actual
+'
+
 test_expect_success 'rerere and rerere forget' '
 	mkdir .git/rr-cache &&
 	prime_resolve_undo &&
-- 
2.41.0-459-gb4fce4b6e4


^ permalink raw reply related	[flat|nested] only message in thread

only message in thread, other threads:[~2023-07-27 19:24 UTC | newest]

Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-07-27 19:24 [PATCH] update-index: do not read HEAD and MERGE_HEAD unconditionally Junio C Hamano

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).