summaryrefslogtreecommitdiff
path: root/t/t6042-merge-rename-corner-cases.sh
diff options
context:
space:
mode:
authorLibravatar Johannes Schindelin <johannes.schindelin@gmx.de>2019-01-17 00:29:21 -0800
committerLibravatar Junio C Hamano <gitster@pobox.com>2019-01-17 12:57:12 -0800
commitda43c07294a349199b74387a2907be56d3fcdf1b (patch)
treedcd3c5ff3985ad0c5393b92fd3c806ed52fd3ab3 /t/t6042-merge-rename-corner-cases.sh
parentSecond batch after 2.20 (diff)
downloadtgif-da43c07294a349199b74387a2907be56d3fcdf1b.tar.xz
t6042: work around speed optimization on Windows
When Git determines whether a file has changed, it looks at the mtime, at the file size, and to detect changes even if the mtime is the same (on Windows, the mtime granularity is 100ns, read: if two files are written within the same 100ns time slot, they have the same mtime) and even if the file size is the same, Git also looks at the inode/device numbers. This design obviously comes from a Linux background, where `lstat()` calls were designed to be cheap. On Windows, there is no `lstat()`. It has to be emulated. And while obtaining the mtime and the file size is not all that expensive (you can get both with a single `GetFileAttributesW()` call), obtaining the equivalent of the inode and device numbers is very expensive (it requires a call to `GetFileInformationByHandle()`, which in turn requires a file handle, which is *a lot* more expensive than one might imagine). As it is very uncommon for developers to modify files within 100ns time slots, Git for Windows chooses not to fill inode/device numbers properly, but simply sets them to 0. However, in t6042 the files file_v1 and file_v2 are typically written within the same 100ns time slot, and they do not differ in file size. So the minor modification is not picked up. Let's work around this issue by avoiding the `git mv` calls in the 'mod6-setup: chains of rename/rename(1to2) and rename/rename(2to1)' test case. The target files are overwritten anyway, so it is not like we really rename those files. This fixes the issue because `git add` will now add the files as new files (as opposed to existing, just renamed files). Functionally, we do not change anything because we replace two `git mv <old> <new>` calls (where `<new>` is completely overwritten and `git add`ed later anyway) by `git rm <old>` calls (removing other files, too, that are also completely overwritten and `git add`ed later). Reviewed-by: Elijah Newren <newren@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 't/t6042-merge-rename-corner-cases.sh')
-rwxr-xr-xt/t6042-merge-rename-corner-cases.sh4
1 files changed, 2 insertions, 2 deletions
diff --git a/t/t6042-merge-rename-corner-cases.sh b/t/t6042-merge-rename-corner-cases.sh
index 7cc34e7579..09dfa8bd92 100755
--- a/t/t6042-merge-rename-corner-cases.sh
+++ b/t/t6042-merge-rename-corner-cases.sh
@@ -1175,7 +1175,7 @@ test_expect_success 'setup nested conflicts from rename/rename(2to1)' '
# Handle the left side
git checkout L &&
- git mv one three &&
+ git rm one two &&
mv -f file_v2 three &&
mv -f file_v5 two &&
git add two three &&
@@ -1183,7 +1183,7 @@ test_expect_success 'setup nested conflicts from rename/rename(2to1)' '
# Handle the right side
git checkout R &&
- git mv two three &&
+ git rm one two &&
mv -f file_v3 one &&
mv -f file_v6 three &&
git add one three &&