git/list[1] front-page[2] threads[3] people[4] search[5] about
 

[PATCH v4 2/2] merge-recursive: fix the refresh logic in update_file_flags

From
Elijah Newren via GitGitGadget <gitgitgadget@gmail.com>
Date
Feb 19, 2020, 17:04 UTC
Message-ID
<ba297fd67bb98bd06408241030cf42f410d5d366.1582131847.git.gitgitgadget@gmail.com>
In-Reply-To
<pull.712.v4.git.git.1582131847.gitgitgadget@gmail.com>
From: Elijah Newren <newren@gmail.com>
If we need to delete a higher stage entry in the index to place the file
at stage 0, then we'll lose that file's stat information.  In such
situations we may still be able to detect that the file on disk is the
version we want (as noted by our comment in the code:
  /* do not overwrite file if already present */
), but we do still need to update the mtime since we are creating a new
cache_entry for that file.  Update the logic used to determine whether
we refresh a file's mtime.
Signed-off-by: Elijah Newren <newren@gmail.com>
---
 merge-recursive.c                    | 7 +++++--
 t/t3433-rebase-across-mode-change.sh | 2 +-
 2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/merge-recursive.c b/merge-recursive.c
index aee1769a7ac..e6f943c5ccc 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -998,10 +998,13 @@ static int update_file_flags(struct merge_options *opt,
 		free(buf);
 	}
 update_index:
-	if (!ret && update_cache)
-		if (add_cacheinfo(opt, contents, path, 0, update_wd,
+	if (!ret && update_cache) {
+		int refresh = (!opt->priv->call_depth &&
+			       contents->mode != S_IFGITLINK);
+		if (add_cacheinfo(opt, contents, path, 0, refresh,
 				  ADD_CACHE_OK_TO_ADD))
 			return -1;
+	}
 	return ret;
 }
 
diff --git a/t/t3433-rebase-across-mode-change.sh b/t/t3433-rebase-across-mode-change.sh
index f11fc35c3ee..05df964670f 100755
--- a/t/t3433-rebase-across-mode-change.sh
+++ b/t/t3433-rebase-across-mode-change.sh
@@ -33,7 +33,7 @@ test_expect_success 'rebase changes with the apply backend' '
 	git rebase side1
 '
 
-test_expect_failure 'rebase changes with the merge backend' '
+test_expect_success 'rebase changes with the merge backend' '
 	test_when_finished "git rebase --abort || true" &&
 	git checkout -b merge-backend side2 &&
 	git rebase -m side1
-- 
gitgitgadget
Previous: Elijah Newren via GitGitGadgetNext: Junio C Hamano
Message 16 of 20 in “t3424: new rebase testcase documenting a stat-dirty-like failure”
  1. t3424: new rebase testcase documenting a stat-dirty-like failureElijah Newren via GitGitGadget, Feb 17, 2020
  2. Elijah NewrenFeb 17, 2020
  3. Phillip WoodFeb 18, 2020
  4. Elijah NewrenFeb 18, 2020
  5. Phillip WoodFeb 19, 2020
  6. Elijah NewrenFeb 19, 2020
  7. Junio C HamanoFeb 19, 2020
  8. Phillip WoodFeb 19, 2020
  9. Johannes SchindelinFeb 18, 2020
  10. Elijah NewrenFeb 18, 2020
  11. t3424: new rebase testcase documenting a stat-dirty-like failureElijah Newren via GitGitGadget, Feb 18, 2020
  12. Junio C HamanoFeb 18, 2020
  13. Elijah NewrenFeb 18, 2020
  14. t3433: new rebase testcase documenting a stat-dirty-like failureElijah Newren via GitGitGadget, Feb 18, 2020
  15. 0/2 t3433: new rebase testcase documenting a stat-dirty-like failureElijah Newren via GitGitGadget, Feb 19, 2020
  16. 2/2 merge-recursive: fix the refresh logic in update_file_flagsElijah Newren via GitGitGadget, Feb 19, 2020
  17. Junio C HamanoFeb 19, 2020
  18. Elijah NewrenFeb 19, 2020
  19. Junio C HamanoFeb 19, 2020
  20. 1/2 t3433: new rebase testcase documenting a stat-dirty-like failureElijah Newren via GitGitGadget, Feb 19, 2020

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.