merge-recursive: fix the refresh logic in update_file_flags
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> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Elijah Newren committed
Feb 19, 2020 at 17:04 UTC
fb1c18fc466c6a9c6ea1b072c9db93c0046f4cbd
2 files changed
+6
-3
merge-recursive.c
+5
-2
@@ -998,10 +998,13 @@ static int update_file_flags(struct merge_options *opt,
998
free(buf);
999
}
1000
update_index:
1001
- if (!ret && update_cache)
1002
- if (add_cacheinfo(opt, contents, path, 0, update_wd,
1001
+ if (!ret && update_cache) {
1002
+ int refresh = (!opt->priv->call_depth &&
1003
+ contents->mode != S_IFGITLINK);
1004
+ if (add_cacheinfo(opt, contents, path, 0, refresh,
1005
ADD_CACHE_OK_TO_ADD))
1006
return -1;
1007
+ }
1008
return ret;
1009
}
1010
t/t3433-rebase-across-mode-change.sh
+1
-1
@@ -33,7 +33,7 @@ test_expect_success 'rebase changes with the apply backend' '
33
git rebase side1
34
'
35
36
-test_expect_failure 'rebase changes with the merge backend' '
36
+test_expect_success 'rebase changes with the merge backend' '
37
test_when_finished "git rebase --abort || true" &&
38
git checkout -b merge-backend side2 &&
39
git rebase -m side1