git/t/t6022-merge-rename.sh

911 lines
23 KiB
Bash
Raw Normal View History

#!/bin/sh
test_description='Merge-recursive merging renames'
. ./test-lib.sh
modify () {
sed -e "$1" <"$2" >"$2.x" &&
mv "$2.x" "$2"
}
test_expect_success 'setup' '
cat >A <<-\EOF &&
a aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
b bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
c cccccccccccccccccccccccccccccccccccccccccccccccc
d dddddddddddddddddddddddddddddddddddddddddddddddd
e eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
f ffffffffffffffffffffffffffffffffffffffffffffffff
g gggggggggggggggggggggggggggggggggggggggggggggggg
h hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh
i iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii
j jjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjj
k kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk
l llllllllllllllllllllllllllllllllllllllllllllllll
m mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm
n nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn
o oooooooooooooooooooooooooooooooooooooooooooooooo
EOF
cat >M <<-\EOF &&
A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
B BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
C CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
D DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD
E EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
F FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
G GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG
H HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
I IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII
J JJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJ
K KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK
L LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL
M MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM
N NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
O OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
EOF
git add A M &&
git commit -m "initial has A and M" &&
git branch white &&
git branch red &&
git branch blue &&
git branch yellow &&
git branch change &&
git branch change+rename &&
sed -e "/^g /s/.*/g : master changes a line/" <A >A+ &&
mv A+ A &&
git commit -a -m "master updates A" &&
git checkout yellow &&
rm -f M &&
git commit -a -m "yellow removes M" &&
git checkout white &&
sed -e "/^g /s/.*/g : white changes a line/" <A >B &&
sed -e "/^G /s/.*/G : colored branch changes a line/" <M >N &&
rm -f A M &&
git update-index --add --remove A B M N &&
git commit -m "white renames A->B, M->N" &&
git checkout red &&
sed -e "/^g /s/.*/g : red changes a line/" <A >B &&
sed -e "/^G /s/.*/G : colored branch changes a line/" <M >N &&
rm -f A M &&
git update-index --add --remove A B M N &&
git commit -m "red renames A->B, M->N" &&
git checkout blue &&
sed -e "/^g /s/.*/g : blue changes a line/" <A >C &&
sed -e "/^G /s/.*/G : colored branch changes a line/" <M >N &&
rm -f A M &&
git update-index --add --remove A C M N &&
git commit -m "blue renames A->C, M->N" &&
git checkout change &&
sed -e "/^g /s/.*/g : changed line/" <A >A+ &&
mv A+ A &&
git commit -q -a -m "changed" &&
git checkout change+rename &&
sed -e "/^g /s/.*/g : changed line/" <A >B &&
rm A &&
git update-index --add B &&
git commit -q -a -m "changed and renamed" &&
git checkout master
'
test_expect_success 'pull renaming branch into unrenaming one' \
'
git show-branch &&
test_expect_code 1 git pull . white &&
git ls-files -s &&
git ls-files -u B >b.stages &&
test_line_count = 3 b.stages &&
git ls-files -s N >n.stages &&
test_line_count = 1 n.stages &&
sed -ne "/^g/{
p
q
}" B | grep master &&
git diff --exit-code white N
'
test_expect_success 'pull renaming branch into another renaming one' \
'
rm -f B &&
git reset --hard &&
git checkout red &&
test_expect_code 1 git pull . white &&
git ls-files -u B >b.stages &&
test_line_count = 3 b.stages &&
git ls-files -s N >n.stages &&
test_line_count = 1 n.stages &&
sed -ne "/^g/{
p
q
}" B | grep red &&
git diff --exit-code white N
'
test_expect_success 'pull unrenaming branch into renaming one' \
'
git reset --hard &&
git show-branch &&
test_expect_code 1 git pull . master &&
git ls-files -u B >b.stages &&
test_line_count = 3 b.stages &&
git ls-files -s N >n.stages &&
test_line_count = 1 n.stages &&
sed -ne "/^g/{
p
q
}" B | grep red &&
git diff --exit-code white N
'
test_expect_success 'pull conflicting renames' \
'
git reset --hard &&
git show-branch &&
test_expect_code 1 git pull . blue &&
git ls-files -u A >a.stages &&
test_line_count = 1 a.stages &&
git ls-files -u B >b.stages &&
test_line_count = 1 b.stages &&
git ls-files -u C >c.stages &&
test_line_count = 1 c.stages &&
git ls-files -s N >n.stages &&
test_line_count = 1 n.stages &&
sed -ne "/^g/{
p
q
}" B | grep red &&
git diff --exit-code white N
'
test_expect_success 'interference with untracked working tree file' '
git reset --hard &&
git show-branch &&
echo >A this file should not matter &&
test_expect_code 1 git pull . white &&
test_path_is_file A
'
test_expect_success 'interference with untracked working tree file' '
git reset --hard &&
git checkout white &&
git show-branch &&
rm -f A &&
echo >A this file should not matter &&
test_expect_code 1 git pull . red &&
test_path_is_file A
'
test_expect_success 'interference with untracked working tree file' '
git reset --hard &&
rm -f A M &&
git checkout -f master &&
git tag -f anchor &&
git show-branch &&
git pull . yellow &&
test_path_is_missing M &&
git reset --hard anchor
'
test_expect_success 'updated working tree file should prevent the merge' '
git reset --hard &&
rm -f A M &&
git checkout -f master &&
git tag -f anchor &&
git show-branch &&
echo >>M one line addition &&
cat M >M.saved &&
test_expect_code 128 git pull . yellow &&
test_cmp M M.saved &&
rm -f M.saved
'
test_expect_success 'updated working tree file should prevent the merge' '
git reset --hard &&
rm -f A M &&
git checkout -f master &&
git tag -f anchor &&
git show-branch &&
echo >>M one line addition &&
cat M >M.saved &&
git update-index M &&
test_expect_code 128 git pull . yellow &&
test_cmp M M.saved &&
rm -f M.saved
'
test_expect_success 'interference with untracked working tree file' '
git reset --hard &&
rm -f A M &&
git checkout -f yellow &&
git tag -f anchor &&
git show-branch &&
echo >M this file should not matter &&
git pull . master &&
test_path_is_file M &&
! {
git ls-files -s |
grep M
} &&
git reset --hard anchor
'
test_expect_success 'merge of identical changes in a renamed file' '
rm -f A M N &&
git reset --hard &&
git checkout change+rename &&
t6022, t6046: fix flaky files-are-updated checks Several tests wanted to verify that files were actually modified by a merge, which it would do by checking that the mtime was updated. In order to avoid problems with the merge completing so fast that the mtime at the beginning and end of the operation was the same, these tests would first set the mtime of a file to something "old". This "old" value was usually determined as current system clock minus one second, truncated to the nearest integer. Unfortunately, it appears the system clock and filesystem clock are different and comparing across the two runs into race problems resulting in flaky tests. From https://stackoverflow.com/questions/14392975/timestamp-accuracy-on-ext4-sub-millsecond: date will call the gettimeofday system call which will always return the most accurate time available based on the cached kernel time, adjusted by the CPU cycle time if available to give nanosecond resolution. The timestamps stored in the file system however, are only based on the cached kernel time. ie The time calculated at the last timer interrupt. and from https://apenwarr.ca/log/20181113: Does mtime get set to >= the current time? No, this depends on clock granularity. For example, gettimeofday() can return times in microseconds on my system, but ext4 rounds timestamps down to the previous ~10ms (but not exactly 10ms) increment, with the surprising result that a newly-created file is almost always created in the past: $ python -c " import os, time t0 = time.time() open('testfile', 'w').close() print os.stat('testfile').st_mtime - t0 " -0.00234484672546 So, instead of trying to compare across what are effectively two different clocks, just avoid using the system clock. Any new updates to files have to give an mtime at least as big as what is already in the file, so we could define "old" as one second before the mtime found in the file before the merge starts. But, to avoid problems with leap seconds, ntp updates, filesystems that only provide two second resolution, and other such weirdness, let's just pick an hour before the mtime found in the file before the merge starts. Also, clarify in one test where we check the mtime of different files that it really was intentional. I totally forgot the reasons for that and assumed it was a bug when asked. Reported-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-13 20:03:02 +00:00
test-tool chmtime --get -3600 B >old-mtime &&
GIT_MERGE_VERBOSITY=3 git merge change >out &&
test-tool chmtime --get B >new-mtime &&
test_cmp old-mtime new-mtime &&
git reset --hard HEAD^ &&
git checkout change &&
t6022, t6046: fix flaky files-are-updated checks Several tests wanted to verify that files were actually modified by a merge, which it would do by checking that the mtime was updated. In order to avoid problems with the merge completing so fast that the mtime at the beginning and end of the operation was the same, these tests would first set the mtime of a file to something "old". This "old" value was usually determined as current system clock minus one second, truncated to the nearest integer. Unfortunately, it appears the system clock and filesystem clock are different and comparing across the two runs into race problems resulting in flaky tests. From https://stackoverflow.com/questions/14392975/timestamp-accuracy-on-ext4-sub-millsecond: date will call the gettimeofday system call which will always return the most accurate time available based on the cached kernel time, adjusted by the CPU cycle time if available to give nanosecond resolution. The timestamps stored in the file system however, are only based on the cached kernel time. ie The time calculated at the last timer interrupt. and from https://apenwarr.ca/log/20181113: Does mtime get set to >= the current time? No, this depends on clock granularity. For example, gettimeofday() can return times in microseconds on my system, but ext4 rounds timestamps down to the previous ~10ms (but not exactly 10ms) increment, with the surprising result that a newly-created file is almost always created in the past: $ python -c " import os, time t0 = time.time() open('testfile', 'w').close() print os.stat('testfile').st_mtime - t0 " -0.00234484672546 So, instead of trying to compare across what are effectively two different clocks, just avoid using the system clock. Any new updates to files have to give an mtime at least as big as what is already in the file, so we could define "old" as one second before the mtime found in the file before the merge starts. But, to avoid problems with leap seconds, ntp updates, filesystems that only provide two second resolution, and other such weirdness, let's just pick an hour before the mtime found in the file before the merge starts. Also, clarify in one test where we check the mtime of different files that it really was intentional. I totally forgot the reasons for that and assumed it was a bug when asked. Reported-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-13 20:03:02 +00:00
# A will be renamed to B; we check mtimes and file presence
test_path_is_missing B &&
test-tool chmtime --get -3600 A >old-mtime &&
GIT_MERGE_VERBOSITY=3 git merge change+rename >out &&
t6022, t6046: fix flaky files-are-updated checks Several tests wanted to verify that files were actually modified by a merge, which it would do by checking that the mtime was updated. In order to avoid problems with the merge completing so fast that the mtime at the beginning and end of the operation was the same, these tests would first set the mtime of a file to something "old". This "old" value was usually determined as current system clock minus one second, truncated to the nearest integer. Unfortunately, it appears the system clock and filesystem clock are different and comparing across the two runs into race problems resulting in flaky tests. From https://stackoverflow.com/questions/14392975/timestamp-accuracy-on-ext4-sub-millsecond: date will call the gettimeofday system call which will always return the most accurate time available based on the cached kernel time, adjusted by the CPU cycle time if available to give nanosecond resolution. The timestamps stored in the file system however, are only based on the cached kernel time. ie The time calculated at the last timer interrupt. and from https://apenwarr.ca/log/20181113: Does mtime get set to >= the current time? No, this depends on clock granularity. For example, gettimeofday() can return times in microseconds on my system, but ext4 rounds timestamps down to the previous ~10ms (but not exactly 10ms) increment, with the surprising result that a newly-created file is almost always created in the past: $ python -c " import os, time t0 = time.time() open('testfile', 'w').close() print os.stat('testfile').st_mtime - t0 " -0.00234484672546 So, instead of trying to compare across what are effectively two different clocks, just avoid using the system clock. Any new updates to files have to give an mtime at least as big as what is already in the file, so we could define "old" as one second before the mtime found in the file before the merge starts. But, to avoid problems with leap seconds, ntp updates, filesystems that only provide two second resolution, and other such weirdness, let's just pick an hour before the mtime found in the file before the merge starts. Also, clarify in one test where we check the mtime of different files that it really was intentional. I totally forgot the reasons for that and assumed it was a bug when asked. Reported-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-13 20:03:02 +00:00
test_path_is_missing A &&
test-tool chmtime --get B >new-mtime &&
test $(cat old-mtime) -lt $(cat new-mtime)
'
test_expect_success 'setup for rename + d/f conflicts' '
git reset --hard &&
git checkout --orphan dir-in-way &&
git rm -rf . &&
git clean -fdqx &&
mkdir sub &&
mkdir dir &&
printf "1\n2\n3\n4\n5\n6\n7\n8\n9\n10\n" >sub/file &&
echo foo >dir/file-in-the-way &&
git add -A &&
git commit -m "Common commit" &&
echo 11 >>sub/file &&
echo more >>dir/file-in-the-way &&
git add -u &&
git commit -m "Commit to merge, with dir in the way" &&
git checkout -b dir-not-in-way &&
git reset --soft HEAD^ &&
git rm -rf dir &&
git commit -m "Commit to merge, with dir removed" -- dir sub/file &&
git checkout -b renamed-file-has-no-conflicts dir-in-way~1 &&
git rm -rf dir &&
git rm sub/file &&
printf "1\n2\n3\n4\n5555\n6\n7\n8\n9\n10\n" >dir &&
git add dir &&
git commit -m "Independent change" &&
git checkout -b renamed-file-has-conflicts dir-in-way~1 &&
git rm -rf dir &&
git mv sub/file dir &&
echo 12 >>dir &&
git add dir &&
git commit -m "Conflicting change"
'
test_expect_success 'Rename+D/F conflict; renamed file merges + dir not in way' '
git reset --hard &&
git checkout -q renamed-file-has-no-conflicts^0 &&
git merge --strategy=recursive dir-not-in-way &&
git diff --quiet &&
test_path_is_file dir &&
test_write_lines 1 2 3 4 5555 6 7 8 9 10 11 >expected &&
test_cmp expected dir
'
test_expect_success 'Rename+D/F conflict; renamed file merges but dir in way' '
git reset --hard &&
rm -rf dir~* &&
git checkout -q renamed-file-has-no-conflicts^0 &&
test_must_fail git merge --strategy=recursive dir-in-way >output &&
test_i18ngrep "CONFLICT (modify/delete): dir/file-in-the-way" output &&
test_i18ngrep "Auto-merging dir" output &&
test_i18ngrep "Adding as dir~HEAD instead" output &&
test 3 -eq "$(git ls-files -u | wc -l)" &&
test 2 -eq "$(git ls-files -u dir/file-in-the-way | wc -l)" &&
test_must_fail git diff --quiet &&
test_must_fail git diff --cached --quiet &&
test_path_is_file dir/file-in-the-way &&
test_path_is_file dir~HEAD &&
test_cmp expected dir~HEAD
'
test_expect_success 'Same as previous, but merged other way' '
git reset --hard &&
rm -rf dir~* &&
git checkout -q dir-in-way^0 &&
test_must_fail git merge --strategy=recursive renamed-file-has-no-conflicts >output 2>errors &&
! grep "error: refusing to lose untracked file at" errors &&
test_i18ngrep "CONFLICT (modify/delete): dir/file-in-the-way" output &&
test_i18ngrep "Auto-merging dir" output &&
test_i18ngrep "Adding as dir~renamed-file-has-no-conflicts instead" output &&
test 3 -eq "$(git ls-files -u | wc -l)" &&
test 2 -eq "$(git ls-files -u dir/file-in-the-way | wc -l)" &&
test_must_fail git diff --quiet &&
test_must_fail git diff --cached --quiet &&
test_path_is_file dir/file-in-the-way &&
test_path_is_file dir~renamed-file-has-no-conflicts &&
test_cmp expected dir~renamed-file-has-no-conflicts
'
test_expect_success 'Rename+D/F conflict; renamed file cannot merge, dir not in way' '
git reset --hard &&
rm -rf dir~* &&
git checkout -q renamed-file-has-conflicts^0 &&
test_must_fail git merge --strategy=recursive dir-not-in-way &&
test 3 -eq "$(git ls-files -u | wc -l)" &&
test 3 -eq "$(git ls-files -u dir | wc -l)" &&
test_must_fail git diff --quiet &&
test_must_fail git diff --cached --quiet &&
test_path_is_file dir &&
cat >expected <<-\EOF &&
1
2
3
4
5
6
7
8
9
10
<<<<<<< HEAD:dir
12
=======
11
>>>>>>> dir-not-in-way:sub/file
EOF
test_cmp expected dir
'
test_expect_success 'Rename+D/F conflict; renamed file cannot merge and dir in the way' '
modify s/dir-not-in-way/dir-in-way/ expected &&
git reset --hard &&
rm -rf dir~* &&
git checkout -q renamed-file-has-conflicts^0 &&
test_must_fail git merge --strategy=recursive dir-in-way &&
test 5 -eq "$(git ls-files -u | wc -l)" &&
test 3 -eq "$(git ls-files -u dir | grep -v file-in-the-way | wc -l)" &&
test 2 -eq "$(git ls-files -u dir/file-in-the-way | wc -l)" &&
test_must_fail git diff --quiet &&
test_must_fail git diff --cached --quiet &&
test_path_is_file dir/file-in-the-way &&
test_path_is_file dir~HEAD &&
test_cmp expected dir~HEAD
'
test_expect_success 'Same as previous, but merged other way' '
git reset --hard &&
rm -rf dir~* &&
git checkout -q dir-in-way^0 &&
test_must_fail git merge --strategy=recursive renamed-file-has-conflicts &&
test 5 -eq "$(git ls-files -u | wc -l)" &&
test 3 -eq "$(git ls-files -u dir | grep -v file-in-the-way | wc -l)" &&
test 2 -eq "$(git ls-files -u dir/file-in-the-way | wc -l)" &&
test_must_fail git diff --quiet &&
test_must_fail git diff --cached --quiet &&
test_path_is_file dir/file-in-the-way &&
test_path_is_file dir~renamed-file-has-conflicts &&
cat >expected <<-\EOF &&
1
2
3
4
5
6
7
8
9
10
<<<<<<< HEAD:sub/file
11
=======
12
>>>>>>> renamed-file-has-conflicts:dir
EOF
test_cmp expected dir~renamed-file-has-conflicts
'
test_expect_success 'setup both rename source and destination involved in D/F conflict' '
git reset --hard &&
git checkout --orphan rename-dest &&
git rm -rf . &&
git clean -fdqx &&
mkdir one &&
echo stuff >one/file &&
git add -A &&
git commit -m "Common commit" &&
git mv one/file destdir &&
git commit -m "Renamed to destdir" &&
git checkout -b source-conflict HEAD~1 &&
git rm -rf one &&
mkdir destdir &&
touch one destdir/foo &&
git add -A &&
git commit -m "Conflicts in the way"
'
test_expect_success 'both rename source and destination involved in D/F conflict' '
git reset --hard &&
rm -rf dir~* &&
git checkout -q rename-dest^0 &&
test_must_fail git merge --strategy=recursive source-conflict &&
test 1 -eq "$(git ls-files -u | wc -l)" &&
test_must_fail git diff --quiet &&
test_path_is_file destdir/foo &&
test_path_is_file one &&
test_path_is_file destdir~HEAD &&
test "stuff" = "$(cat destdir~HEAD)"
'
test_expect_success 'setup pair rename to parent of other (D/F conflicts)' '
git reset --hard &&
git checkout --orphan rename-two &&
git rm -rf . &&
git clean -fdqx &&
mkdir one &&
mkdir two &&
echo stuff >one/file &&
echo other >two/file &&
git add -A &&
git commit -m "Common commit" &&
git rm -rf one &&
git mv two/file one &&
git commit -m "Rename two/file -> one" &&
git checkout -b rename-one HEAD~1 &&
git rm -rf two &&
git mv one/file two &&
rm -r one &&
git commit -m "Rename one/file -> two"
'
test_expect_success 'pair rename to parent of other (D/F conflicts) w/ untracked dir' '
git checkout -q rename-one^0 &&
mkdir one &&
test_must_fail git merge --strategy=recursive rename-two &&
test 2 -eq "$(git ls-files -u | wc -l)" &&
test 1 -eq "$(git ls-files -u one | wc -l)" &&
test 1 -eq "$(git ls-files -u two | wc -l)" &&
test_must_fail git diff --quiet &&
test 4 -eq $(find . | grep -v .git | wc -l) &&
test_path_is_dir one &&
test_path_is_file one~rename-two &&
test_path_is_file two &&
test "other" = $(cat one~rename-two) &&
test "stuff" = $(cat two)
'
test_expect_success 'pair rename to parent of other (D/F conflicts) w/ clean start' '
git reset --hard &&
git clean -fdqx &&
test_must_fail git merge --strategy=recursive rename-two &&
test 2 -eq "$(git ls-files -u | wc -l)" &&
test 1 -eq "$(git ls-files -u one | wc -l)" &&
test 1 -eq "$(git ls-files -u two | wc -l)" &&
test_must_fail git diff --quiet &&
test 3 -eq $(find . | grep -v .git | wc -l) &&
test_path_is_file one &&
test_path_is_file two &&
test "other" = $(cat one) &&
test "stuff" = $(cat two)
'
test_expect_success 'setup rename of one file to two, with directories in the way' '
git reset --hard &&
git checkout --orphan first-rename &&
git rm -rf . &&
git clean -fdqx &&
echo stuff >original &&
git add -A &&
git commit -m "Common commit" &&
mkdir two &&
>two/file &&
git add two/file &&
git mv original one &&
git commit -m "Put two/file in the way, rename to one" &&
git checkout -b second-rename HEAD~1 &&
mkdir one &&
>one/file &&
git add one/file &&
git mv original two &&
git commit -m "Put one/file in the way, rename to two"
'
test_expect_success 'check handling of differently renamed file with D/F conflicts' '
git checkout -q first-rename^0 &&
test_must_fail git merge --strategy=recursive second-rename &&
test 5 -eq "$(git ls-files -s | wc -l)" &&
test 3 -eq "$(git ls-files -u | wc -l)" &&
test 1 -eq "$(git ls-files -u one | wc -l)" &&
test 1 -eq "$(git ls-files -u two | wc -l)" &&
test 1 -eq "$(git ls-files -u original | wc -l)" &&
test 2 -eq "$(git ls-files -o | wc -l)" &&
test_path_is_file one/file &&
test_path_is_file two/file &&
test_path_is_file one~HEAD &&
test_path_is_file two~second-rename &&
test_path_is_missing original
'
test_expect_success 'setup rename one file to two; directories moving out of the way' '
git reset --hard &&
git checkout --orphan first-rename-redo &&
git rm -rf . &&
git clean -fdqx &&
echo stuff >original &&
mkdir one two &&
touch one/file two/file &&
git add -A &&
git commit -m "Common commit" &&
git rm -rf one &&
git mv original one &&
git commit -m "Rename to one" &&
git checkout -b second-rename-redo HEAD~1 &&
git rm -rf two &&
git mv original two &&
git commit -m "Rename to two"
'
test_expect_success 'check handling of differently renamed file with D/F conflicts' '
git checkout -q first-rename-redo^0 &&
test_must_fail git merge --strategy=recursive second-rename-redo &&
test 3 -eq "$(git ls-files -u | wc -l)" &&
test 1 -eq "$(git ls-files -u one | wc -l)" &&
test 1 -eq "$(git ls-files -u two | wc -l)" &&
test 1 -eq "$(git ls-files -u original | wc -l)" &&
test 0 -eq "$(git ls-files -o | wc -l)" &&
test_path_is_file one &&
test_path_is_file two &&
test_path_is_missing original
'
test_expect_success 'setup avoid unnecessary update, normal rename' '
git reset --hard &&
git checkout --orphan avoid-unnecessary-update-1 &&
git rm -rf . &&
git clean -fdqx &&
printf "1\n2\n3\n4\n5\n6\n7\n8\n9\n10\n" >original &&
git add -A &&
git commit -m "Common commit" &&
git mv original rename &&
echo 11 >>rename &&
git add -u &&
git commit -m "Renamed and modified" &&
git checkout -b merge-branch-1 HEAD~1 &&
echo "random content" >random-file &&
git add -A &&
git commit -m "Random, unrelated changes"
'
merge-recursive: When we detect we can skip an update, actually skip it In 882fd11 (merge-recursive: Delay content merging for renames 2010-09-20), there was code that checked for whether we could skip updating a file in the working directory, based on whether the merged version matched the current working copy. Due to the desire to handle directory/file conflicts that were resolvable, that commit deferred content merging by first updating the index with the unmerged entries and then moving the actual merging (along with the skip-the-content-update check) to another function that ran later in the merge process. As part moving the content merging code, a bug was introduced such that although the message about skipping the update would be printed (whenever GIT_MERGE_VERBOSITY was sufficiently high), the file would be unconditionally updated in the working copy anyway. When we detect that the file does not need to be updated in the working copy, update the index appropriately and then return early before updating the working copy. Note that there was a similar change in b2c8c0a (merge-recursive: When we detect we can skip an update, actually skip it 2011-02-28), but it was reverted by 6db4105 (Revert "Merge branch 'en/merge-recursive'" 2011-05-19) since it did not fix both of the relevant types of unnecessary update breakages and, worse, it made use of some band-aids that caused other problems. The reason this change works is due to the changes earlier in this series to (a) record_df_conflict_files instead of just unlinking them early, (b) allowing make_room_for_path() to remove D/F entries, (c) the splitting of update_stages_and_entry() to have its functionality called at different points, and (d) making the pathnames of the files involved in the merge available to merge_content(). Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-12 05:20:10 +00:00
test_expect_success 'avoid unnecessary update, normal rename' '
git checkout -q avoid-unnecessary-update-1^0 &&
t6022, t6046: fix flaky files-are-updated checks Several tests wanted to verify that files were actually modified by a merge, which it would do by checking that the mtime was updated. In order to avoid problems with the merge completing so fast that the mtime at the beginning and end of the operation was the same, these tests would first set the mtime of a file to something "old". This "old" value was usually determined as current system clock minus one second, truncated to the nearest integer. Unfortunately, it appears the system clock and filesystem clock are different and comparing across the two runs into race problems resulting in flaky tests. From https://stackoverflow.com/questions/14392975/timestamp-accuracy-on-ext4-sub-millsecond: date will call the gettimeofday system call which will always return the most accurate time available based on the cached kernel time, adjusted by the CPU cycle time if available to give nanosecond resolution. The timestamps stored in the file system however, are only based on the cached kernel time. ie The time calculated at the last timer interrupt. and from https://apenwarr.ca/log/20181113: Does mtime get set to >= the current time? No, this depends on clock granularity. For example, gettimeofday() can return times in microseconds on my system, but ext4 rounds timestamps down to the previous ~10ms (but not exactly 10ms) increment, with the surprising result that a newly-created file is almost always created in the past: $ python -c " import os, time t0 = time.time() open('testfile', 'w').close() print os.stat('testfile').st_mtime - t0 " -0.00234484672546 So, instead of trying to compare across what are effectively two different clocks, just avoid using the system clock. Any new updates to files have to give an mtime at least as big as what is already in the file, so we could define "old" as one second before the mtime found in the file before the merge starts. But, to avoid problems with leap seconds, ntp updates, filesystems that only provide two second resolution, and other such weirdness, let's just pick an hour before the mtime found in the file before the merge starts. Also, clarify in one test where we check the mtime of different files that it really was intentional. I totally forgot the reasons for that and assumed it was a bug when asked. Reported-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-13 20:03:02 +00:00
test-tool chmtime --get -3600 rename >expect &&
git merge merge-branch-1 &&
test-tool chmtime --get rename >actual &&
test_cmp expect actual # "rename" should have stayed intact
'
test_expect_success 'setup to test avoiding unnecessary update, with D/F conflict' '
git reset --hard &&
git checkout --orphan avoid-unnecessary-update-2 &&
git rm -rf . &&
git clean -fdqx &&
mkdir df &&
printf "1\n2\n3\n4\n5\n6\n7\n8\n9\n10\n" >df/file &&
git add -A &&
git commit -m "Common commit" &&
git mv df/file temp &&
rm -rf df &&
git mv temp df &&
echo 11 >>df &&
git add -u &&
git commit -m "Renamed and modified" &&
git checkout -b merge-branch-2 HEAD~1 &&
>unrelated-change &&
git add unrelated-change &&
git commit -m "Only unrelated changes"
'
merge-recursive: When we detect we can skip an update, actually skip it In 882fd11 (merge-recursive: Delay content merging for renames 2010-09-20), there was code that checked for whether we could skip updating a file in the working directory, based on whether the merged version matched the current working copy. Due to the desire to handle directory/file conflicts that were resolvable, that commit deferred content merging by first updating the index with the unmerged entries and then moving the actual merging (along with the skip-the-content-update check) to another function that ran later in the merge process. As part moving the content merging code, a bug was introduced such that although the message about skipping the update would be printed (whenever GIT_MERGE_VERBOSITY was sufficiently high), the file would be unconditionally updated in the working copy anyway. When we detect that the file does not need to be updated in the working copy, update the index appropriately and then return early before updating the working copy. Note that there was a similar change in b2c8c0a (merge-recursive: When we detect we can skip an update, actually skip it 2011-02-28), but it was reverted by 6db4105 (Revert "Merge branch 'en/merge-recursive'" 2011-05-19) since it did not fix both of the relevant types of unnecessary update breakages and, worse, it made use of some band-aids that caused other problems. The reason this change works is due to the changes earlier in this series to (a) record_df_conflict_files instead of just unlinking them early, (b) allowing make_room_for_path() to remove D/F entries, (c) the splitting of update_stages_and_entry() to have its functionality called at different points, and (d) making the pathnames of the files involved in the merge available to merge_content(). Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-12 05:20:10 +00:00
test_expect_success 'avoid unnecessary update, with D/F conflict' '
git checkout -q avoid-unnecessary-update-2^0 &&
t6022, t6046: fix flaky files-are-updated checks Several tests wanted to verify that files were actually modified by a merge, which it would do by checking that the mtime was updated. In order to avoid problems with the merge completing so fast that the mtime at the beginning and end of the operation was the same, these tests would first set the mtime of a file to something "old". This "old" value was usually determined as current system clock minus one second, truncated to the nearest integer. Unfortunately, it appears the system clock and filesystem clock are different and comparing across the two runs into race problems resulting in flaky tests. From https://stackoverflow.com/questions/14392975/timestamp-accuracy-on-ext4-sub-millsecond: date will call the gettimeofday system call which will always return the most accurate time available based on the cached kernel time, adjusted by the CPU cycle time if available to give nanosecond resolution. The timestamps stored in the file system however, are only based on the cached kernel time. ie The time calculated at the last timer interrupt. and from https://apenwarr.ca/log/20181113: Does mtime get set to >= the current time? No, this depends on clock granularity. For example, gettimeofday() can return times in microseconds on my system, but ext4 rounds timestamps down to the previous ~10ms (but not exactly 10ms) increment, with the surprising result that a newly-created file is almost always created in the past: $ python -c " import os, time t0 = time.time() open('testfile', 'w').close() print os.stat('testfile').st_mtime - t0 " -0.00234484672546 So, instead of trying to compare across what are effectively two different clocks, just avoid using the system clock. Any new updates to files have to give an mtime at least as big as what is already in the file, so we could define "old" as one second before the mtime found in the file before the merge starts. But, to avoid problems with leap seconds, ntp updates, filesystems that only provide two second resolution, and other such weirdness, let's just pick an hour before the mtime found in the file before the merge starts. Also, clarify in one test where we check the mtime of different files that it really was intentional. I totally forgot the reasons for that and assumed it was a bug when asked. Reported-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-13 20:03:02 +00:00
test-tool chmtime --get -3600 df >expect &&
git merge merge-branch-2 &&
test-tool chmtime --get df >actual &&
test_cmp expect actual # "df" should have stayed intact
'
test_expect_success 'setup avoid unnecessary update, dir->(file,nothing)' '
git rm -rf . &&
git clean -fdqx &&
rm -rf .git &&
git init &&
>irrelevant &&
mkdir df &&
>df/file &&
git add -A &&
git commit -mA &&
git checkout -b side &&
git rm -rf df &&
git commit -mB &&
git checkout master &&
git rm -rf df &&
echo bla >df &&
git add -A &&
git commit -m "Add a newfile"
'
test_expect_success 'avoid unnecessary update, dir->(file,nothing)' '
git checkout -q master^0 &&
t6022, t6046: fix flaky files-are-updated checks Several tests wanted to verify that files were actually modified by a merge, which it would do by checking that the mtime was updated. In order to avoid problems with the merge completing so fast that the mtime at the beginning and end of the operation was the same, these tests would first set the mtime of a file to something "old". This "old" value was usually determined as current system clock minus one second, truncated to the nearest integer. Unfortunately, it appears the system clock and filesystem clock are different and comparing across the two runs into race problems resulting in flaky tests. From https://stackoverflow.com/questions/14392975/timestamp-accuracy-on-ext4-sub-millsecond: date will call the gettimeofday system call which will always return the most accurate time available based on the cached kernel time, adjusted by the CPU cycle time if available to give nanosecond resolution. The timestamps stored in the file system however, are only based on the cached kernel time. ie The time calculated at the last timer interrupt. and from https://apenwarr.ca/log/20181113: Does mtime get set to >= the current time? No, this depends on clock granularity. For example, gettimeofday() can return times in microseconds on my system, but ext4 rounds timestamps down to the previous ~10ms (but not exactly 10ms) increment, with the surprising result that a newly-created file is almost always created in the past: $ python -c " import os, time t0 = time.time() open('testfile', 'w').close() print os.stat('testfile').st_mtime - t0 " -0.00234484672546 So, instead of trying to compare across what are effectively two different clocks, just avoid using the system clock. Any new updates to files have to give an mtime at least as big as what is already in the file, so we could define "old" as one second before the mtime found in the file before the merge starts. But, to avoid problems with leap seconds, ntp updates, filesystems that only provide two second resolution, and other such weirdness, let's just pick an hour before the mtime found in the file before the merge starts. Also, clarify in one test where we check the mtime of different files that it really was intentional. I totally forgot the reasons for that and assumed it was a bug when asked. Reported-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-13 20:03:02 +00:00
test-tool chmtime --get -3600 df >expect &&
git merge side &&
test-tool chmtime --get df >actual &&
test_cmp expect actual # "df" should have stayed intact
'
test_expect_success 'setup avoid unnecessary update, modify/delete' '
git rm -rf . &&
git clean -fdqx &&
rm -rf .git &&
git init &&
>irrelevant &&
>file &&
git add -A &&
git commit -mA &&
git checkout -b side &&
git rm -f file &&
git commit -m "Delete file" &&
git checkout master &&
echo bla >file &&
git add -A &&
git commit -m "Modify file"
'
test_expect_success 'avoid unnecessary update, modify/delete' '
git checkout -q master^0 &&
t6022, t6046: fix flaky files-are-updated checks Several tests wanted to verify that files were actually modified by a merge, which it would do by checking that the mtime was updated. In order to avoid problems with the merge completing so fast that the mtime at the beginning and end of the operation was the same, these tests would first set the mtime of a file to something "old". This "old" value was usually determined as current system clock minus one second, truncated to the nearest integer. Unfortunately, it appears the system clock and filesystem clock are different and comparing across the two runs into race problems resulting in flaky tests. From https://stackoverflow.com/questions/14392975/timestamp-accuracy-on-ext4-sub-millsecond: date will call the gettimeofday system call which will always return the most accurate time available based on the cached kernel time, adjusted by the CPU cycle time if available to give nanosecond resolution. The timestamps stored in the file system however, are only based on the cached kernel time. ie The time calculated at the last timer interrupt. and from https://apenwarr.ca/log/20181113: Does mtime get set to >= the current time? No, this depends on clock granularity. For example, gettimeofday() can return times in microseconds on my system, but ext4 rounds timestamps down to the previous ~10ms (but not exactly 10ms) increment, with the surprising result that a newly-created file is almost always created in the past: $ python -c " import os, time t0 = time.time() open('testfile', 'w').close() print os.stat('testfile').st_mtime - t0 " -0.00234484672546 So, instead of trying to compare across what are effectively two different clocks, just avoid using the system clock. Any new updates to files have to give an mtime at least as big as what is already in the file, so we could define "old" as one second before the mtime found in the file before the merge starts. But, to avoid problems with leap seconds, ntp updates, filesystems that only provide two second resolution, and other such weirdness, let's just pick an hour before the mtime found in the file before the merge starts. Also, clarify in one test where we check the mtime of different files that it really was intentional. I totally forgot the reasons for that and assumed it was a bug when asked. Reported-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-13 20:03:02 +00:00
test-tool chmtime --get -3600 file >expect &&
test_must_fail git merge side &&
test-tool chmtime --get file >actual &&
test_cmp expect actual # "file" should have stayed intact
'
test_expect_success 'setup avoid unnecessary update, rename/add-dest' '
git rm -rf . &&
git clean -fdqx &&
rm -rf .git &&
git init &&
printf "1\n2\n3\n4\n5\n6\n7\n8\n" >file &&
git add -A &&
git commit -mA &&
git checkout -b side &&
cp file newfile &&
git add -A &&
git commit -m "Add file copy" &&
git checkout master &&
git mv file newfile &&
git commit -m "Rename file"
'
test_expect_success 'avoid unnecessary update, rename/add-dest' '
git checkout -q master^0 &&
t6022, t6046: fix flaky files-are-updated checks Several tests wanted to verify that files were actually modified by a merge, which it would do by checking that the mtime was updated. In order to avoid problems with the merge completing so fast that the mtime at the beginning and end of the operation was the same, these tests would first set the mtime of a file to something "old". This "old" value was usually determined as current system clock minus one second, truncated to the nearest integer. Unfortunately, it appears the system clock and filesystem clock are different and comparing across the two runs into race problems resulting in flaky tests. From https://stackoverflow.com/questions/14392975/timestamp-accuracy-on-ext4-sub-millsecond: date will call the gettimeofday system call which will always return the most accurate time available based on the cached kernel time, adjusted by the CPU cycle time if available to give nanosecond resolution. The timestamps stored in the file system however, are only based on the cached kernel time. ie The time calculated at the last timer interrupt. and from https://apenwarr.ca/log/20181113: Does mtime get set to >= the current time? No, this depends on clock granularity. For example, gettimeofday() can return times in microseconds on my system, but ext4 rounds timestamps down to the previous ~10ms (but not exactly 10ms) increment, with the surprising result that a newly-created file is almost always created in the past: $ python -c " import os, time t0 = time.time() open('testfile', 'w').close() print os.stat('testfile').st_mtime - t0 " -0.00234484672546 So, instead of trying to compare across what are effectively two different clocks, just avoid using the system clock. Any new updates to files have to give an mtime at least as big as what is already in the file, so we could define "old" as one second before the mtime found in the file before the merge starts. But, to avoid problems with leap seconds, ntp updates, filesystems that only provide two second resolution, and other such weirdness, let's just pick an hour before the mtime found in the file before the merge starts. Also, clarify in one test where we check the mtime of different files that it really was intentional. I totally forgot the reasons for that and assumed it was a bug when asked. Reported-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-13 20:03:02 +00:00
test-tool chmtime --get -3600 newfile >expect &&
git merge side &&
test-tool chmtime --get newfile >actual &&
test_cmp expect actual # "file" should have stayed intact
'
test_expect_success 'setup merge of rename + small change' '
git reset --hard &&
git checkout --orphan rename-plus-small-change &&
git rm -rf . &&
git clean -fdqx &&
echo ORIGINAL >file &&
git add file &&
test_tick &&
git commit -m Initial &&
git checkout -b rename_branch &&
git mv file renamed_file &&
git commit -m Rename &&
git checkout rename-plus-small-change &&
echo NEW-VERSION >file &&
git commit -a -m Reformat
'
test_expect_success 'merge rename + small change' '
git merge rename_branch &&
test 1 -eq $(git ls-files -s | wc -l) &&
test 0 -eq $(git ls-files -o | wc -l) &&
test $(git rev-parse HEAD:renamed_file) = $(git rev-parse HEAD~1:file)
'
test_expect_success 'setup for use of extended merge markers' '
git rm -rf . &&
git clean -fdqx &&
rm -rf .git &&
git init &&
printf "1\n2\n3\n4\n5\n6\n7\n8\n" >original_file &&
git add original_file &&
git commit -mA &&
git checkout -b rename &&
echo 9 >>original_file &&
git add original_file &&
git mv original_file renamed_file &&
git commit -mB &&
git checkout master &&
echo 8.5 >>original_file &&
git add original_file &&
git commit -mC
'
test_expect_success 'merge master into rename has correct extended markers' '
git checkout rename^0 &&
test_must_fail git merge -s recursive master^0 &&
cat >expected <<-\EOF &&
1
2
3
4
5
6
7
8
<<<<<<< HEAD:renamed_file
9
=======
8.5
>>>>>>> master^0:original_file
EOF
test_cmp expected renamed_file
'
test_expect_success 'merge rename into master has correct extended markers' '
git reset --hard &&
git checkout master^0 &&
test_must_fail git merge -s recursive rename^0 &&
cat >expected <<-\EOF &&
1
2
3
4
5
6
7
8
<<<<<<< HEAD:original_file
8.5
=======
9
>>>>>>> rename^0:renamed_file
EOF
test_cmp expected renamed_file
'
test_expect_success 'setup spurious "refusing to lose untracked" message' '
git rm -rf . &&
git clean -fdqx &&
rm -rf .git &&
git init &&
> irrelevant_file &&
printf "1\n2\n3\n4\n5\n6\n7\n8\n" >original_file &&
git add irrelevant_file original_file &&
git commit -mA &&
git checkout -b rename &&
git mv original_file renamed_file &&
git commit -mB &&
git checkout master &&
git rm original_file &&
git commit -mC
'
test_expect_success 'no spurious "refusing to lose untracked" message' '
git checkout master^0 &&
test_must_fail git merge rename^0 2>errors.txt &&
! grep "refusing to lose untracked file" errors.txt
'
test_expect_success 'do not follow renames for empty files' '
git checkout -f -b empty-base &&
>empty1 &&
git add empty1 &&
git commit -m base &&
echo content >empty1 &&
git add empty1 &&
git commit -m fill &&
git checkout -b empty-topic HEAD^ &&
git mv empty1 empty2 &&
git commit -m rename &&
test_must_fail git merge empty-base &&
test_must_be_empty empty2
'
test_done