2005-12-11 20:44:46 +00:00
|
|
|
#!/bin/sh
|
|
|
|
|
|
|
|
test_description='Merge-recursive merging renames'
|
2020-11-18 23:44:38 +00:00
|
|
|
GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main
|
tests: mark tests relying on the current default for `init.defaultBranch`
In addition to the manual adjustment to let the `linux-gcc` CI job run
the test suite with `master` and then with `main`, this patch makes sure
that GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME is set in all test scripts
that currently rely on the initial branch name being `master by default.
To determine which test scripts to mark up, the first step was to
force-set the default branch name to `master` in
- all test scripts that contain the keyword `master`,
- t4211, which expects `t/t4211/history.export` with a hard-coded ref to
initialize the default branch,
- t5560 because it sources `t/t556x_common` which uses `master`,
- t8002 and t8012 because both source `t/annotate-tests.sh` which also
uses `master`)
This trick was performed by this command:
$ sed -i '/^ *\. \.\/\(test-lib\|lib-\(bash\|cvs\|git-svn\)\|gitweb-lib\)\.sh$/i\
GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master\
export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME\
' $(git grep -l master t/t[0-9]*.sh) \
t/t4211*.sh t/t5560*.sh t/t8002*.sh t/t8012*.sh
After that, careful, manual inspection revealed that some of the test
scripts containing the needle `master` do not actually rely on a
specific default branch name: either they mention `master` only in a
comment, or they initialize that branch specificially, or they do not
actually refer to the current default branch. Therefore, the
aforementioned modification was undone in those test scripts thusly:
$ git checkout HEAD -- \
t/t0027-auto-crlf.sh t/t0060-path-utils.sh \
t/t1011-read-tree-sparse-checkout.sh \
t/t1305-config-include.sh t/t1309-early-config.sh \
t/t1402-check-ref-format.sh t/t1450-fsck.sh \
t/t2024-checkout-dwim.sh \
t/t2106-update-index-assume-unchanged.sh \
t/t3040-subprojects-basic.sh t/t3301-notes.sh \
t/t3308-notes-merge.sh t/t3423-rebase-reword.sh \
t/t3436-rebase-more-options.sh \
t/t4015-diff-whitespace.sh t/t4257-am-interactive.sh \
t/t5323-pack-redundant.sh t/t5401-update-hooks.sh \
t/t5511-refspec.sh t/t5526-fetch-submodules.sh \
t/t5529-push-errors.sh t/t5530-upload-pack-error.sh \
t/t5548-push-porcelain.sh \
t/t5552-skipping-fetch-negotiator.sh \
t/t5572-pull-submodule.sh t/t5608-clone-2gb.sh \
t/t5614-clone-submodules-shallow.sh \
t/t7508-status.sh t/t7606-merge-custom.sh \
t/t9302-fast-import-unpack-limit.sh
We excluded one set of test scripts in these commands, though: the range
of `git p4` tests. The reason? `git p4` stores the (foreign) remote
branch in the branch called `p4/master`, which is obviously not the
default branch. Manual analysis revealed that only five of these tests
actually require a specific default branch name to pass; They were
modified thusly:
$ sed -i '/^ *\. \.\/lib-git-p4\.sh$/i\
GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master\
export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME\
' t/t980[0167]*.sh t/t9811*.sh
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-18 23:44:19 +00:00
|
|
|
export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME
|
|
|
|
|
2005-12-11 20:44:46 +00:00
|
|
|
. ./test-lib.sh
|
|
|
|
|
2010-09-20 08:28:37 +00:00
|
|
|
modify () {
|
|
|
|
sed -e "$1" <"$2" >"$2.x" &&
|
|
|
|
mv "$2.x" "$2"
|
|
|
|
}
|
|
|
|
|
2020-02-27 00:14:20 +00:00
|
|
|
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 &&
|
|
|
|
|
2020-11-18 23:44:38 +00:00
|
|
|
sed -e "/^g /s/.*/g : main changes a line/" <A >A+ &&
|
2020-02-27 00:14:20 +00:00
|
|
|
mv A+ A &&
|
2020-11-18 23:44:38 +00:00
|
|
|
git commit -a -m "main updates A" &&
|
2020-02-27 00:14:20 +00:00
|
|
|
|
|
|
|
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" &&
|
|
|
|
|
2020-11-18 23:44:38 +00:00
|
|
|
git checkout main
|
2020-02-27 00:14:20 +00:00
|
|
|
'
|
2005-12-11 20:44:46 +00:00
|
|
|
|
|
|
|
test_expect_success 'pull renaming branch into unrenaming one' \
|
|
|
|
'
|
2010-10-31 07:34:44 +00:00
|
|
|
git show-branch &&
|
2021-07-22 05:04:48 +00:00
|
|
|
test_expect_code 1 git pull --no-rebase . white &&
|
2010-10-31 07:34:44 +00:00
|
|
|
git ls-files -s &&
|
2021-07-04 05:46:12 +00:00
|
|
|
test_stdout_line_count = 3 git ls-files -u B &&
|
|
|
|
test_stdout_line_count = 1 git ls-files -s N &&
|
2005-12-11 20:44:46 +00:00
|
|
|
sed -ne "/^g/{
|
|
|
|
p
|
|
|
|
q
|
2020-11-18 23:44:38 +00:00
|
|
|
}" B | grep main &&
|
2010-10-31 07:34:44 +00:00
|
|
|
git diff --exit-code white N
|
2005-12-11 20:44:46 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'pull renaming branch into another renaming one' \
|
|
|
|
'
|
2010-10-31 07:34:44 +00:00
|
|
|
rm -f B &&
|
|
|
|
git reset --hard &&
|
|
|
|
git checkout red &&
|
2021-07-22 05:04:48 +00:00
|
|
|
test_expect_code 1 git pull --no-rebase . white &&
|
2021-07-04 05:46:12 +00:00
|
|
|
test_stdout_line_count = 3 git ls-files -u B &&
|
|
|
|
test_stdout_line_count = 1 git ls-files -s N &&
|
2005-12-11 20:44:46 +00:00
|
|
|
sed -ne "/^g/{
|
|
|
|
p
|
|
|
|
q
|
2010-10-31 07:34:44 +00:00
|
|
|
}" B | grep red &&
|
|
|
|
git diff --exit-code white N
|
2005-12-11 20:44:46 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'pull unrenaming branch into renaming one' \
|
|
|
|
'
|
2010-10-31 07:34:44 +00:00
|
|
|
git reset --hard &&
|
|
|
|
git show-branch &&
|
2021-07-22 05:04:48 +00:00
|
|
|
test_expect_code 1 git pull --no-rebase . main &&
|
2021-07-04 05:46:12 +00:00
|
|
|
test_stdout_line_count = 3 git ls-files -u B &&
|
|
|
|
test_stdout_line_count = 1 git ls-files -s N &&
|
2005-12-11 20:44:46 +00:00
|
|
|
sed -ne "/^g/{
|
|
|
|
p
|
|
|
|
q
|
2010-10-31 07:34:44 +00:00
|
|
|
}" B | grep red &&
|
|
|
|
git diff --exit-code white N
|
2005-12-11 20:44:46 +00:00
|
|
|
'
|
|
|
|
|
2005-12-12 00:44:05 +00:00
|
|
|
test_expect_success 'pull conflicting renames' \
|
|
|
|
'
|
2010-10-31 07:34:44 +00:00
|
|
|
git reset --hard &&
|
|
|
|
git show-branch &&
|
2021-07-22 05:04:48 +00:00
|
|
|
test_expect_code 1 git pull --no-rebase . blue &&
|
2021-07-04 05:46:12 +00:00
|
|
|
test_stdout_line_count = 1 git ls-files -u A &&
|
|
|
|
test_stdout_line_count = 1 git ls-files -u B &&
|
|
|
|
test_stdout_line_count = 1 git ls-files -u C &&
|
|
|
|
test_stdout_line_count = 1 git ls-files -s N &&
|
2005-12-12 00:44:05 +00:00
|
|
|
sed -ne "/^g/{
|
|
|
|
p
|
|
|
|
q
|
2010-10-31 07:34:44 +00:00
|
|
|
}" B | grep red &&
|
|
|
|
git diff --exit-code white N
|
2006-10-27 23:07:02 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'interference with untracked working tree file' '
|
2010-10-31 07:34:44 +00:00
|
|
|
git reset --hard &&
|
|
|
|
git show-branch &&
|
|
|
|
echo >A this file should not matter &&
|
2021-07-22 05:04:48 +00:00
|
|
|
test_expect_code 1 git pull --no-rebase . white &&
|
2010-10-31 07:34:44 +00:00
|
|
|
test_path_is_file A
|
2006-10-27 23:07:02 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'interference with untracked working tree file' '
|
2010-10-31 07:34:44 +00:00
|
|
|
git reset --hard &&
|
|
|
|
git checkout white &&
|
|
|
|
git show-branch &&
|
|
|
|
rm -f A &&
|
|
|
|
echo >A this file should not matter &&
|
2021-07-22 05:04:48 +00:00
|
|
|
test_expect_code 1 git pull --no-rebase . red &&
|
2010-10-31 07:34:44 +00:00
|
|
|
test_path_is_file A
|
2006-10-27 23:07:02 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'interference with untracked working tree file' '
|
2010-10-31 07:34:44 +00:00
|
|
|
git reset --hard &&
|
|
|
|
rm -f A M &&
|
2020-11-18 23:44:38 +00:00
|
|
|
git checkout -f main &&
|
2010-10-31 07:34:44 +00:00
|
|
|
git tag -f anchor &&
|
|
|
|
git show-branch &&
|
2021-07-22 05:04:48 +00:00
|
|
|
git pull --no-rebase . yellow &&
|
2010-10-31 07:34:44 +00:00
|
|
|
test_path_is_missing M &&
|
2006-10-27 23:07:02 +00:00
|
|
|
git reset --hard anchor
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'updated working tree file should prevent the merge' '
|
2010-10-31 07:34:44 +00:00
|
|
|
git reset --hard &&
|
|
|
|
rm -f A M &&
|
2020-11-18 23:44:38 +00:00
|
|
|
git checkout -f main &&
|
2010-10-31 07:34:44 +00:00
|
|
|
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 &&
|
2006-10-27 23:07:02 +00:00
|
|
|
rm -f M.saved
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'updated working tree file should prevent the merge' '
|
2010-10-31 07:34:44 +00:00
|
|
|
git reset --hard &&
|
|
|
|
rm -f A M &&
|
2020-11-18 23:44:38 +00:00
|
|
|
git checkout -f main &&
|
2010-10-31 07:34:44 +00:00
|
|
|
git tag -f anchor &&
|
|
|
|
git show-branch &&
|
|
|
|
echo >>M one line addition &&
|
|
|
|
cat M >M.saved &&
|
|
|
|
git update-index M &&
|
2022-07-23 01:53:14 +00:00
|
|
|
test_expect_code 2 git pull --no-rebase . yellow &&
|
2010-10-31 07:34:44 +00:00
|
|
|
test_cmp M M.saved &&
|
2006-10-27 23:07:02 +00:00
|
|
|
rm -f M.saved
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'interference with untracked working tree file' '
|
2010-10-31 07:34:44 +00:00
|
|
|
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 &&
|
2021-07-22 05:04:48 +00:00
|
|
|
git pull --no-rebase . main &&
|
2010-10-31 07:34:44 +00:00
|
|
|
test_path_is_file M &&
|
|
|
|
! {
|
|
|
|
git ls-files -s |
|
|
|
|
grep M
|
|
|
|
} &&
|
2006-10-27 23:07:02 +00:00
|
|
|
git reset --hard anchor
|
2005-12-12 00:44:05 +00:00
|
|
|
'
|
|
|
|
|
2007-04-25 20:07:45 +00:00
|
|
|
test_expect_success 'merge of identical changes in a renamed file' '
|
2010-10-31 07:34:44 +00:00
|
|
|
rm -f A M N &&
|
2007-04-25 20:07:45 +00:00
|
|
|
git reset --hard &&
|
|
|
|
git checkout change+rename &&
|
2020-02-27 00:14:23 +00:00
|
|
|
|
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 &&
|
2018-02-08 15:56:50 +00:00
|
|
|
GIT_MERGE_VERBOSITY=3 git merge change >out &&
|
2020-02-27 00:14:23 +00:00
|
|
|
|
|
|
|
test-tool chmtime --get B >new-mtime &&
|
|
|
|
test_cmp old-mtime new-mtime &&
|
|
|
|
|
2007-04-25 20:07:45 +00:00
|
|
|
git reset --hard HEAD^ &&
|
|
|
|
git checkout change &&
|
2020-02-27 00:14:23 +00:00
|
|
|
|
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 &&
|
2018-02-08 15:56:50 +00:00
|
|
|
GIT_MERGE_VERBOSITY=3 git merge change+rename >out &&
|
2020-02-27 00:14:23 +00:00
|
|
|
|
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 &&
|
2020-02-27 00:14:23 +00:00
|
|
|
test-tool chmtime --get B >new-mtime &&
|
|
|
|
test $(cat old-mtime) -lt $(cat new-mtime)
|
2007-04-25 20:07:45 +00:00
|
|
|
'
|
|
|
|
|
2010-09-20 08:28:37 +00:00
|
|
|
test_expect_success 'setup for rename + d/f conflicts' '
|
|
|
|
git reset --hard &&
|
|
|
|
git checkout --orphan dir-in-way &&
|
|
|
|
git rm -rf . &&
|
2011-08-12 05:19:46 +00:00
|
|
|
git clean -fdqx &&
|
2010-09-20 08:28:37 +00:00
|
|
|
|
|
|
|
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 &&
|
2013-09-04 22:28:45 +00:00
|
|
|
git commit -m "Common commit" &&
|
2010-09-20 08:28:37 +00:00
|
|
|
|
|
|
|
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 &&
|
2020-02-27 00:14:20 +00:00
|
|
|
|
2010-09-20 08:28:37 +00:00
|
|
|
git merge --strategy=recursive dir-not-in-way &&
|
2020-02-27 00:14:20 +00:00
|
|
|
|
2010-09-20 08:28:37 +00:00
|
|
|
git diff --quiet &&
|
2020-02-27 00:14:21 +00:00
|
|
|
test_path_is_file dir &&
|
|
|
|
test_write_lines 1 2 3 4 5555 6 7 8 9 10 11 >expected &&
|
2010-09-20 08:28:37 +00:00
|
|
|
test_cmp expected dir
|
|
|
|
'
|
|
|
|
|
2010-09-20 08:29:07 +00:00
|
|
|
test_expect_success 'Rename+D/F conflict; renamed file merges but dir in way' '
|
2010-09-20 08:28:37 +00:00
|
|
|
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 &&
|
|
|
|
|
2012-07-25 14:53:13 +00:00
|
|
|
test_i18ngrep "CONFLICT (modify/delete): dir/file-in-the-way" output &&
|
|
|
|
test_i18ngrep "Auto-merging dir" output &&
|
2020-10-26 17:01:41 +00:00
|
|
|
if test "$GIT_TEST_MERGE_ALGORITHM" = ort
|
|
|
|
then
|
|
|
|
test_i18ngrep "moving it to dir~HEAD instead" output
|
|
|
|
else
|
|
|
|
test_i18ngrep "Adding as dir~HEAD instead" output
|
|
|
|
fi &&
|
2010-09-20 08:28:37 +00:00
|
|
|
|
2021-07-04 05:46:12 +00:00
|
|
|
test_stdout_line_count = 3 git ls-files -u &&
|
|
|
|
test_stdout_line_count = 2 git ls-files -u dir/file-in-the-way &&
|
2010-09-20 08:28:37 +00:00
|
|
|
|
|
|
|
test_must_fail git diff --quiet &&
|
|
|
|
test_must_fail git diff --cached --quiet &&
|
|
|
|
|
2020-02-27 00:14:21 +00:00
|
|
|
test_path_is_file dir/file-in-the-way &&
|
|
|
|
test_path_is_file dir~HEAD &&
|
2010-09-20 08:28:37 +00:00
|
|
|
test_cmp expected dir~HEAD
|
|
|
|
'
|
|
|
|
|
2010-09-20 08:29:07 +00:00
|
|
|
test_expect_success 'Same as previous, but merged other way' '
|
2010-09-20 08:28:38 +00:00
|
|
|
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 &&
|
2012-07-25 14:53:13 +00:00
|
|
|
test_i18ngrep "CONFLICT (modify/delete): dir/file-in-the-way" output &&
|
|
|
|
test_i18ngrep "Auto-merging dir" output &&
|
2020-10-26 17:01:41 +00:00
|
|
|
if test "$GIT_TEST_MERGE_ALGORITHM" = ort
|
|
|
|
then
|
|
|
|
test_i18ngrep "moving it to dir~renamed-file-has-no-conflicts instead" output
|
|
|
|
else
|
|
|
|
test_i18ngrep "Adding as dir~renamed-file-has-no-conflicts instead" output
|
|
|
|
fi &&
|
2010-09-20 08:28:38 +00:00
|
|
|
|
2021-07-04 05:46:12 +00:00
|
|
|
test_stdout_line_count = 3 git ls-files -u &&
|
|
|
|
test_stdout_line_count = 2 git ls-files -u dir/file-in-the-way &&
|
2010-09-20 08:28:38 +00:00
|
|
|
|
|
|
|
test_must_fail git diff --quiet &&
|
|
|
|
test_must_fail git diff --cached --quiet &&
|
|
|
|
|
2020-02-27 00:14:21 +00:00
|
|
|
test_path_is_file dir/file-in-the-way &&
|
|
|
|
test_path_is_file dir~renamed-file-has-no-conflicts &&
|
2010-09-20 08:28:38 +00:00
|
|
|
test_cmp expected dir~renamed-file-has-no-conflicts
|
|
|
|
'
|
|
|
|
|
2010-09-20 08:29:03 +00:00
|
|
|
test_expect_success 'Rename+D/F conflict; renamed file cannot merge, dir not in way' '
|
2010-09-20 08:28:37 +00:00
|
|
|
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 &&
|
|
|
|
|
2021-07-04 05:46:12 +00:00
|
|
|
test_stdout_line_count = 3 git ls-files -u &&
|
|
|
|
test_stdout_line_count = 3 git ls-files -u dir &&
|
2010-09-20 08:28:37 +00:00
|
|
|
|
|
|
|
test_must_fail git diff --quiet &&
|
|
|
|
test_must_fail git diff --cached --quiet &&
|
|
|
|
|
2020-02-27 00:14:21 +00:00
|
|
|
test_path_is_file dir &&
|
2020-02-27 00:14:20 +00:00
|
|
|
cat >expected <<-\EOF &&
|
|
|
|
1
|
|
|
|
2
|
|
|
|
3
|
|
|
|
4
|
|
|
|
5
|
|
|
|
6
|
|
|
|
7
|
|
|
|
8
|
|
|
|
9
|
|
|
|
10
|
|
|
|
<<<<<<< HEAD:dir
|
|
|
|
12
|
|
|
|
=======
|
|
|
|
11
|
|
|
|
>>>>>>> dir-not-in-way:sub/file
|
|
|
|
EOF
|
2010-09-20 08:28:37 +00:00
|
|
|
test_cmp expected dir
|
|
|
|
'
|
|
|
|
|
2010-09-20 08:29:07 +00:00
|
|
|
test_expect_success 'Rename+D/F conflict; renamed file cannot merge and dir in the way' '
|
2010-09-20 08:28:37 +00:00
|
|
|
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 &&
|
|
|
|
|
2021-07-04 05:46:12 +00:00
|
|
|
test_stdout_line_count = 5 git ls-files -u &&
|
merge tests: expect improved directory/file conflict handling in ort
merge-recursive.c is built on the idea of running unpack_trees() and
then "doing minor touch-ups" to get the result. Unfortunately,
unpack_trees() was run in an update-as-it-goes mode, leading
merge-recursive.c to follow suit and end up with an immediate evaluation
and fix-it-up-as-you-go design. Some things like directory/file
conflicts are not well representable in the index data structure, and
required special extra code to handle. But then when it was discovered
that rename/delete conflicts could also be involved in directory/file
conflicts, the special directory/file conflict handling code had to be
copied to the rename/delete codepath. ...and then it had to be copied
for modify/delete, and for rename/rename(1to2) conflicts, ...and yet it
still missed some. Further, when it was discovered that there were also
file/submodule conflicts and submodule/directory conflicts, we needed to
copy the special submodule handling code to all the special cases
throughout the codebase.
And then it was discovered that our handling of directory/file conflicts
was suboptimal because it would create untracked files to store the
contents of the conflicting file, which would not be cleaned up if
someone were to run a 'git merge --abort' or 'git rebase --abort'. It
was also difficult or scary to try to add or remove the index entries
corresponding to these files given the directory/file conflict in the
index. But changing merge-recursive.c to handle these correctly was a
royal pain because there were so many sites in the code with similar but
not identical code for handling directory/file/submodule conflicts that
would all need to be updated.
I have worked hard to push all directory/file/submodule conflict
handling in merge-ort through a single codepath, and avoid creating
untracked files for storing tracked content (it does record things at
alternate paths, but makes sure they have higher-order stages in the
index).
Since updating merge-recursive is too much work and we don't want to
destabilize it, instead update the testsuite to have different
expectations for relevant directory/file/submodule conflict tests.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-26 17:01:37 +00:00
|
|
|
if test "$GIT_TEST_MERGE_ALGORITHM" = ort
|
|
|
|
then
|
2021-07-04 05:46:12 +00:00
|
|
|
test_stdout_line_count = 3 git ls-files -u dir~HEAD
|
merge tests: expect improved directory/file conflict handling in ort
merge-recursive.c is built on the idea of running unpack_trees() and
then "doing minor touch-ups" to get the result. Unfortunately,
unpack_trees() was run in an update-as-it-goes mode, leading
merge-recursive.c to follow suit and end up with an immediate evaluation
and fix-it-up-as-you-go design. Some things like directory/file
conflicts are not well representable in the index data structure, and
required special extra code to handle. But then when it was discovered
that rename/delete conflicts could also be involved in directory/file
conflicts, the special directory/file conflict handling code had to be
copied to the rename/delete codepath. ...and then it had to be copied
for modify/delete, and for rename/rename(1to2) conflicts, ...and yet it
still missed some. Further, when it was discovered that there were also
file/submodule conflicts and submodule/directory conflicts, we needed to
copy the special submodule handling code to all the special cases
throughout the codebase.
And then it was discovered that our handling of directory/file conflicts
was suboptimal because it would create untracked files to store the
contents of the conflicting file, which would not be cleaned up if
someone were to run a 'git merge --abort' or 'git rebase --abort'. It
was also difficult or scary to try to add or remove the index entries
corresponding to these files given the directory/file conflict in the
index. But changing merge-recursive.c to handle these correctly was a
royal pain because there were so many sites in the code with similar but
not identical code for handling directory/file/submodule conflicts that
would all need to be updated.
I have worked hard to push all directory/file/submodule conflict
handling in merge-ort through a single codepath, and avoid creating
untracked files for storing tracked content (it does record things at
alternate paths, but makes sure they have higher-order stages in the
index).
Since updating merge-recursive is too much work and we don't want to
destabilize it, instead update the testsuite to have different
expectations for relevant directory/file/submodule conflict tests.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-26 17:01:37 +00:00
|
|
|
else
|
2021-07-04 05:46:12 +00:00
|
|
|
git ls-files -u dir >out &&
|
|
|
|
test 3 -eq $(grep -v file-in-the-way out | wc -l) &&
|
|
|
|
rm -f out
|
merge tests: expect improved directory/file conflict handling in ort
merge-recursive.c is built on the idea of running unpack_trees() and
then "doing minor touch-ups" to get the result. Unfortunately,
unpack_trees() was run in an update-as-it-goes mode, leading
merge-recursive.c to follow suit and end up with an immediate evaluation
and fix-it-up-as-you-go design. Some things like directory/file
conflicts are not well representable in the index data structure, and
required special extra code to handle. But then when it was discovered
that rename/delete conflicts could also be involved in directory/file
conflicts, the special directory/file conflict handling code had to be
copied to the rename/delete codepath. ...and then it had to be copied
for modify/delete, and for rename/rename(1to2) conflicts, ...and yet it
still missed some. Further, when it was discovered that there were also
file/submodule conflicts and submodule/directory conflicts, we needed to
copy the special submodule handling code to all the special cases
throughout the codebase.
And then it was discovered that our handling of directory/file conflicts
was suboptimal because it would create untracked files to store the
contents of the conflicting file, which would not be cleaned up if
someone were to run a 'git merge --abort' or 'git rebase --abort'. It
was also difficult or scary to try to add or remove the index entries
corresponding to these files given the directory/file conflict in the
index. But changing merge-recursive.c to handle these correctly was a
royal pain because there were so many sites in the code with similar but
not identical code for handling directory/file/submodule conflicts that
would all need to be updated.
I have worked hard to push all directory/file/submodule conflict
handling in merge-ort through a single codepath, and avoid creating
untracked files for storing tracked content (it does record things at
alternate paths, but makes sure they have higher-order stages in the
index).
Since updating merge-recursive is too much work and we don't want to
destabilize it, instead update the testsuite to have different
expectations for relevant directory/file/submodule conflict tests.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-26 17:01:37 +00:00
|
|
|
fi &&
|
2021-07-04 05:46:12 +00:00
|
|
|
test_stdout_line_count = 2 git ls-files -u dir/file-in-the-way &&
|
2010-09-20 08:28:37 +00:00
|
|
|
|
|
|
|
test_must_fail git diff --quiet &&
|
|
|
|
test_must_fail git diff --cached --quiet &&
|
|
|
|
|
2020-02-27 00:14:21 +00:00
|
|
|
test_path_is_file dir/file-in-the-way &&
|
|
|
|
test_path_is_file dir~HEAD &&
|
2010-09-20 08:28:37 +00:00
|
|
|
test_cmp expected dir~HEAD
|
|
|
|
'
|
|
|
|
|
2010-09-20 08:29:07 +00:00
|
|
|
test_expect_success 'Same as previous, but merged other way' '
|
2010-09-20 08:28:38 +00:00
|
|
|
git reset --hard &&
|
|
|
|
rm -rf dir~* &&
|
|
|
|
git checkout -q dir-in-way^0 &&
|
|
|
|
test_must_fail git merge --strategy=recursive renamed-file-has-conflicts &&
|
|
|
|
|
2021-07-04 05:46:12 +00:00
|
|
|
test_stdout_line_count = 5 git ls-files -u &&
|
merge tests: expect improved directory/file conflict handling in ort
merge-recursive.c is built on the idea of running unpack_trees() and
then "doing minor touch-ups" to get the result. Unfortunately,
unpack_trees() was run in an update-as-it-goes mode, leading
merge-recursive.c to follow suit and end up with an immediate evaluation
and fix-it-up-as-you-go design. Some things like directory/file
conflicts are not well representable in the index data structure, and
required special extra code to handle. But then when it was discovered
that rename/delete conflicts could also be involved in directory/file
conflicts, the special directory/file conflict handling code had to be
copied to the rename/delete codepath. ...and then it had to be copied
for modify/delete, and for rename/rename(1to2) conflicts, ...and yet it
still missed some. Further, when it was discovered that there were also
file/submodule conflicts and submodule/directory conflicts, we needed to
copy the special submodule handling code to all the special cases
throughout the codebase.
And then it was discovered that our handling of directory/file conflicts
was suboptimal because it would create untracked files to store the
contents of the conflicting file, which would not be cleaned up if
someone were to run a 'git merge --abort' or 'git rebase --abort'. It
was also difficult or scary to try to add or remove the index entries
corresponding to these files given the directory/file conflict in the
index. But changing merge-recursive.c to handle these correctly was a
royal pain because there were so many sites in the code with similar but
not identical code for handling directory/file/submodule conflicts that
would all need to be updated.
I have worked hard to push all directory/file/submodule conflict
handling in merge-ort through a single codepath, and avoid creating
untracked files for storing tracked content (it does record things at
alternate paths, but makes sure they have higher-order stages in the
index).
Since updating merge-recursive is too much work and we don't want to
destabilize it, instead update the testsuite to have different
expectations for relevant directory/file/submodule conflict tests.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-26 17:01:37 +00:00
|
|
|
if test "$GIT_TEST_MERGE_ALGORITHM" = ort
|
|
|
|
then
|
2021-07-04 05:46:12 +00:00
|
|
|
test_stdout_line_count = 3 git ls-files -u dir~renamed-file-has-conflicts
|
merge tests: expect improved directory/file conflict handling in ort
merge-recursive.c is built on the idea of running unpack_trees() and
then "doing minor touch-ups" to get the result. Unfortunately,
unpack_trees() was run in an update-as-it-goes mode, leading
merge-recursive.c to follow suit and end up with an immediate evaluation
and fix-it-up-as-you-go design. Some things like directory/file
conflicts are not well representable in the index data structure, and
required special extra code to handle. But then when it was discovered
that rename/delete conflicts could also be involved in directory/file
conflicts, the special directory/file conflict handling code had to be
copied to the rename/delete codepath. ...and then it had to be copied
for modify/delete, and for rename/rename(1to2) conflicts, ...and yet it
still missed some. Further, when it was discovered that there were also
file/submodule conflicts and submodule/directory conflicts, we needed to
copy the special submodule handling code to all the special cases
throughout the codebase.
And then it was discovered that our handling of directory/file conflicts
was suboptimal because it would create untracked files to store the
contents of the conflicting file, which would not be cleaned up if
someone were to run a 'git merge --abort' or 'git rebase --abort'. It
was also difficult or scary to try to add or remove the index entries
corresponding to these files given the directory/file conflict in the
index. But changing merge-recursive.c to handle these correctly was a
royal pain because there were so many sites in the code with similar but
not identical code for handling directory/file/submodule conflicts that
would all need to be updated.
I have worked hard to push all directory/file/submodule conflict
handling in merge-ort through a single codepath, and avoid creating
untracked files for storing tracked content (it does record things at
alternate paths, but makes sure they have higher-order stages in the
index).
Since updating merge-recursive is too much work and we don't want to
destabilize it, instead update the testsuite to have different
expectations for relevant directory/file/submodule conflict tests.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-26 17:01:37 +00:00
|
|
|
else
|
2021-07-04 05:46:12 +00:00
|
|
|
git ls-files -u dir >out &&
|
|
|
|
test 3 -eq $(grep -v file-in-the-way out | wc -l) &&
|
|
|
|
rm -f out
|
merge tests: expect improved directory/file conflict handling in ort
merge-recursive.c is built on the idea of running unpack_trees() and
then "doing minor touch-ups" to get the result. Unfortunately,
unpack_trees() was run in an update-as-it-goes mode, leading
merge-recursive.c to follow suit and end up with an immediate evaluation
and fix-it-up-as-you-go design. Some things like directory/file
conflicts are not well representable in the index data structure, and
required special extra code to handle. But then when it was discovered
that rename/delete conflicts could also be involved in directory/file
conflicts, the special directory/file conflict handling code had to be
copied to the rename/delete codepath. ...and then it had to be copied
for modify/delete, and for rename/rename(1to2) conflicts, ...and yet it
still missed some. Further, when it was discovered that there were also
file/submodule conflicts and submodule/directory conflicts, we needed to
copy the special submodule handling code to all the special cases
throughout the codebase.
And then it was discovered that our handling of directory/file conflicts
was suboptimal because it would create untracked files to store the
contents of the conflicting file, which would not be cleaned up if
someone were to run a 'git merge --abort' or 'git rebase --abort'. It
was also difficult or scary to try to add or remove the index entries
corresponding to these files given the directory/file conflict in the
index. But changing merge-recursive.c to handle these correctly was a
royal pain because there were so many sites in the code with similar but
not identical code for handling directory/file/submodule conflicts that
would all need to be updated.
I have worked hard to push all directory/file/submodule conflict
handling in merge-ort through a single codepath, and avoid creating
untracked files for storing tracked content (it does record things at
alternate paths, but makes sure they have higher-order stages in the
index).
Since updating merge-recursive is too much work and we don't want to
destabilize it, instead update the testsuite to have different
expectations for relevant directory/file/submodule conflict tests.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-26 17:01:37 +00:00
|
|
|
fi &&
|
2021-07-04 05:46:12 +00:00
|
|
|
test_stdout_line_count = 2 git ls-files -u dir/file-in-the-way &&
|
2010-09-20 08:28:38 +00:00
|
|
|
|
|
|
|
test_must_fail git diff --quiet &&
|
|
|
|
test_must_fail git diff --cached --quiet &&
|
|
|
|
|
2020-02-27 00:14:21 +00:00
|
|
|
test_path_is_file dir/file-in-the-way &&
|
|
|
|
test_path_is_file dir~renamed-file-has-conflicts &&
|
2020-02-27 00:14:20 +00:00
|
|
|
cat >expected <<-\EOF &&
|
|
|
|
1
|
|
|
|
2
|
|
|
|
3
|
|
|
|
4
|
|
|
|
5
|
|
|
|
6
|
|
|
|
7
|
|
|
|
8
|
|
|
|
9
|
|
|
|
10
|
|
|
|
<<<<<<< HEAD:sub/file
|
|
|
|
11
|
|
|
|
=======
|
|
|
|
12
|
|
|
|
>>>>>>> renamed-file-has-conflicts:dir
|
|
|
|
EOF
|
2010-09-20 08:28:38 +00:00
|
|
|
test_cmp expected dir~renamed-file-has-conflicts
|
|
|
|
'
|
|
|
|
|
2010-09-20 08:28:39 +00:00
|
|
|
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 &&
|
2013-09-04 22:28:45 +00:00
|
|
|
git commit -m "Common commit" &&
|
2010-09-20 08:28:39 +00:00
|
|
|
|
|
|
|
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"
|
|
|
|
'
|
|
|
|
|
2010-09-20 08:29:05 +00:00
|
|
|
test_expect_success 'both rename source and destination involved in D/F conflict' '
|
2010-09-20 08:28:39 +00:00
|
|
|
git reset --hard &&
|
|
|
|
rm -rf dir~* &&
|
|
|
|
git checkout -q rename-dest^0 &&
|
|
|
|
test_must_fail git merge --strategy=recursive source-conflict &&
|
|
|
|
|
merge tests: expect improved directory/file conflict handling in ort
merge-recursive.c is built on the idea of running unpack_trees() and
then "doing minor touch-ups" to get the result. Unfortunately,
unpack_trees() was run in an update-as-it-goes mode, leading
merge-recursive.c to follow suit and end up with an immediate evaluation
and fix-it-up-as-you-go design. Some things like directory/file
conflicts are not well representable in the index data structure, and
required special extra code to handle. But then when it was discovered
that rename/delete conflicts could also be involved in directory/file
conflicts, the special directory/file conflict handling code had to be
copied to the rename/delete codepath. ...and then it had to be copied
for modify/delete, and for rename/rename(1to2) conflicts, ...and yet it
still missed some. Further, when it was discovered that there were also
file/submodule conflicts and submodule/directory conflicts, we needed to
copy the special submodule handling code to all the special cases
throughout the codebase.
And then it was discovered that our handling of directory/file conflicts
was suboptimal because it would create untracked files to store the
contents of the conflicting file, which would not be cleaned up if
someone were to run a 'git merge --abort' or 'git rebase --abort'. It
was also difficult or scary to try to add or remove the index entries
corresponding to these files given the directory/file conflict in the
index. But changing merge-recursive.c to handle these correctly was a
royal pain because there were so many sites in the code with similar but
not identical code for handling directory/file/submodule conflicts that
would all need to be updated.
I have worked hard to push all directory/file/submodule conflict
handling in merge-ort through a single codepath, and avoid creating
untracked files for storing tracked content (it does record things at
alternate paths, but makes sure they have higher-order stages in the
index).
Since updating merge-recursive is too much work and we don't want to
destabilize it, instead update the testsuite to have different
expectations for relevant directory/file/submodule conflict tests.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-26 17:01:37 +00:00
|
|
|
if test "$GIT_TEST_MERGE_ALGORITHM" = ort
|
|
|
|
then
|
2021-07-04 05:46:12 +00:00
|
|
|
test_stdout_line_count = 2 git ls-files -u
|
merge tests: expect improved directory/file conflict handling in ort
merge-recursive.c is built on the idea of running unpack_trees() and
then "doing minor touch-ups" to get the result. Unfortunately,
unpack_trees() was run in an update-as-it-goes mode, leading
merge-recursive.c to follow suit and end up with an immediate evaluation
and fix-it-up-as-you-go design. Some things like directory/file
conflicts are not well representable in the index data structure, and
required special extra code to handle. But then when it was discovered
that rename/delete conflicts could also be involved in directory/file
conflicts, the special directory/file conflict handling code had to be
copied to the rename/delete codepath. ...and then it had to be copied
for modify/delete, and for rename/rename(1to2) conflicts, ...and yet it
still missed some. Further, when it was discovered that there were also
file/submodule conflicts and submodule/directory conflicts, we needed to
copy the special submodule handling code to all the special cases
throughout the codebase.
And then it was discovered that our handling of directory/file conflicts
was suboptimal because it would create untracked files to store the
contents of the conflicting file, which would not be cleaned up if
someone were to run a 'git merge --abort' or 'git rebase --abort'. It
was also difficult or scary to try to add or remove the index entries
corresponding to these files given the directory/file conflict in the
index. But changing merge-recursive.c to handle these correctly was a
royal pain because there were so many sites in the code with similar but
not identical code for handling directory/file/submodule conflicts that
would all need to be updated.
I have worked hard to push all directory/file/submodule conflict
handling in merge-ort through a single codepath, and avoid creating
untracked files for storing tracked content (it does record things at
alternate paths, but makes sure they have higher-order stages in the
index).
Since updating merge-recursive is too much work and we don't want to
destabilize it, instead update the testsuite to have different
expectations for relevant directory/file/submodule conflict tests.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-26 17:01:37 +00:00
|
|
|
else
|
2021-07-04 05:46:12 +00:00
|
|
|
test_stdout_line_count = 1 git ls-files -u
|
merge tests: expect improved directory/file conflict handling in ort
merge-recursive.c is built on the idea of running unpack_trees() and
then "doing minor touch-ups" to get the result. Unfortunately,
unpack_trees() was run in an update-as-it-goes mode, leading
merge-recursive.c to follow suit and end up with an immediate evaluation
and fix-it-up-as-you-go design. Some things like directory/file
conflicts are not well representable in the index data structure, and
required special extra code to handle. But then when it was discovered
that rename/delete conflicts could also be involved in directory/file
conflicts, the special directory/file conflict handling code had to be
copied to the rename/delete codepath. ...and then it had to be copied
for modify/delete, and for rename/rename(1to2) conflicts, ...and yet it
still missed some. Further, when it was discovered that there were also
file/submodule conflicts and submodule/directory conflicts, we needed to
copy the special submodule handling code to all the special cases
throughout the codebase.
And then it was discovered that our handling of directory/file conflicts
was suboptimal because it would create untracked files to store the
contents of the conflicting file, which would not be cleaned up if
someone were to run a 'git merge --abort' or 'git rebase --abort'. It
was also difficult or scary to try to add or remove the index entries
corresponding to these files given the directory/file conflict in the
index. But changing merge-recursive.c to handle these correctly was a
royal pain because there were so many sites in the code with similar but
not identical code for handling directory/file/submodule conflicts that
would all need to be updated.
I have worked hard to push all directory/file/submodule conflict
handling in merge-ort through a single codepath, and avoid creating
untracked files for storing tracked content (it does record things at
alternate paths, but makes sure they have higher-order stages in the
index).
Since updating merge-recursive is too much work and we don't want to
destabilize it, instead update the testsuite to have different
expectations for relevant directory/file/submodule conflict tests.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-26 17:01:37 +00:00
|
|
|
fi &&
|
2010-09-20 08:28:39 +00:00
|
|
|
|
|
|
|
test_must_fail git diff --quiet &&
|
|
|
|
|
2020-02-27 00:14:21 +00:00
|
|
|
test_path_is_file destdir/foo &&
|
|
|
|
test_path_is_file one &&
|
|
|
|
test_path_is_file destdir~HEAD &&
|
2010-09-20 08:28:39 +00:00
|
|
|
test "stuff" = "$(cat destdir~HEAD)"
|
|
|
|
'
|
|
|
|
|
2010-09-20 08:28:40 +00:00
|
|
|
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 &&
|
2013-09-04 22:28:45 +00:00
|
|
|
git commit -m "Common commit" &&
|
2010-09-20 08:28:40 +00:00
|
|
|
|
|
|
|
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"
|
|
|
|
'
|
|
|
|
|
merge tests: expect improved directory/file conflict handling in ort
merge-recursive.c is built on the idea of running unpack_trees() and
then "doing minor touch-ups" to get the result. Unfortunately,
unpack_trees() was run in an update-as-it-goes mode, leading
merge-recursive.c to follow suit and end up with an immediate evaluation
and fix-it-up-as-you-go design. Some things like directory/file
conflicts are not well representable in the index data structure, and
required special extra code to handle. But then when it was discovered
that rename/delete conflicts could also be involved in directory/file
conflicts, the special directory/file conflict handling code had to be
copied to the rename/delete codepath. ...and then it had to be copied
for modify/delete, and for rename/rename(1to2) conflicts, ...and yet it
still missed some. Further, when it was discovered that there were also
file/submodule conflicts and submodule/directory conflicts, we needed to
copy the special submodule handling code to all the special cases
throughout the codebase.
And then it was discovered that our handling of directory/file conflicts
was suboptimal because it would create untracked files to store the
contents of the conflicting file, which would not be cleaned up if
someone were to run a 'git merge --abort' or 'git rebase --abort'. It
was also difficult or scary to try to add or remove the index entries
corresponding to these files given the directory/file conflict in the
index. But changing merge-recursive.c to handle these correctly was a
royal pain because there were so many sites in the code with similar but
not identical code for handling directory/file/submodule conflicts that
would all need to be updated.
I have worked hard to push all directory/file/submodule conflict
handling in merge-ort through a single codepath, and avoid creating
untracked files for storing tracked content (it does record things at
alternate paths, but makes sure they have higher-order stages in the
index).
Since updating merge-recursive is too much work and we don't want to
destabilize it, instead update the testsuite to have different
expectations for relevant directory/file/submodule conflict tests.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-26 17:01:37 +00:00
|
|
|
if test "$GIT_TEST_MERGE_ALGORITHM" = ort
|
|
|
|
then
|
|
|
|
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 &&
|
2010-09-20 08:28:40 +00:00
|
|
|
|
2021-07-04 05:46:12 +00:00
|
|
|
test_stdout_line_count = 4 git ls-files -u &&
|
|
|
|
test_stdout_line_count = 2 git ls-files -u one &&
|
|
|
|
test_stdout_line_count = 2 git ls-files -u two &&
|
2010-09-20 08:28:40 +00:00
|
|
|
|
merge tests: expect improved directory/file conflict handling in ort
merge-recursive.c is built on the idea of running unpack_trees() and
then "doing minor touch-ups" to get the result. Unfortunately,
unpack_trees() was run in an update-as-it-goes mode, leading
merge-recursive.c to follow suit and end up with an immediate evaluation
and fix-it-up-as-you-go design. Some things like directory/file
conflicts are not well representable in the index data structure, and
required special extra code to handle. But then when it was discovered
that rename/delete conflicts could also be involved in directory/file
conflicts, the special directory/file conflict handling code had to be
copied to the rename/delete codepath. ...and then it had to be copied
for modify/delete, and for rename/rename(1to2) conflicts, ...and yet it
still missed some. Further, when it was discovered that there were also
file/submodule conflicts and submodule/directory conflicts, we needed to
copy the special submodule handling code to all the special cases
throughout the codebase.
And then it was discovered that our handling of directory/file conflicts
was suboptimal because it would create untracked files to store the
contents of the conflicting file, which would not be cleaned up if
someone were to run a 'git merge --abort' or 'git rebase --abort'. It
was also difficult or scary to try to add or remove the index entries
corresponding to these files given the directory/file conflict in the
index. But changing merge-recursive.c to handle these correctly was a
royal pain because there were so many sites in the code with similar but
not identical code for handling directory/file/submodule conflicts that
would all need to be updated.
I have worked hard to push all directory/file/submodule conflict
handling in merge-ort through a single codepath, and avoid creating
untracked files for storing tracked content (it does record things at
alternate paths, but makes sure they have higher-order stages in the
index).
Since updating merge-recursive is too much work and we don't want to
destabilize it, instead update the testsuite to have different
expectations for relevant directory/file/submodule conflict tests.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-26 17:01:37 +00:00
|
|
|
test_must_fail git diff --quiet &&
|
2010-09-20 08:28:40 +00:00
|
|
|
|
merge tests: expect improved directory/file conflict handling in ort
merge-recursive.c is built on the idea of running unpack_trees() and
then "doing minor touch-ups" to get the result. Unfortunately,
unpack_trees() was run in an update-as-it-goes mode, leading
merge-recursive.c to follow suit and end up with an immediate evaluation
and fix-it-up-as-you-go design. Some things like directory/file
conflicts are not well representable in the index data structure, and
required special extra code to handle. But then when it was discovered
that rename/delete conflicts could also be involved in directory/file
conflicts, the special directory/file conflict handling code had to be
copied to the rename/delete codepath. ...and then it had to be copied
for modify/delete, and for rename/rename(1to2) conflicts, ...and yet it
still missed some. Further, when it was discovered that there were also
file/submodule conflicts and submodule/directory conflicts, we needed to
copy the special submodule handling code to all the special cases
throughout the codebase.
And then it was discovered that our handling of directory/file conflicts
was suboptimal because it would create untracked files to store the
contents of the conflicting file, which would not be cleaned up if
someone were to run a 'git merge --abort' or 'git rebase --abort'. It
was also difficult or scary to try to add or remove the index entries
corresponding to these files given the directory/file conflict in the
index. But changing merge-recursive.c to handle these correctly was a
royal pain because there were so many sites in the code with similar but
not identical code for handling directory/file/submodule conflicts that
would all need to be updated.
I have worked hard to push all directory/file/submodule conflict
handling in merge-ort through a single codepath, and avoid creating
untracked files for storing tracked content (it does record things at
alternate paths, but makes sure they have higher-order stages in the
index).
Since updating merge-recursive is too much work and we don't want to
destabilize it, instead update the testsuite to have different
expectations for relevant directory/file/submodule conflict tests.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-26 17:01:37 +00:00
|
|
|
test 3 -eq $(find . | grep -v .git | wc -l) &&
|
2010-09-20 08:28:40 +00:00
|
|
|
|
merge tests: expect improved directory/file conflict handling in ort
merge-recursive.c is built on the idea of running unpack_trees() and
then "doing minor touch-ups" to get the result. Unfortunately,
unpack_trees() was run in an update-as-it-goes mode, leading
merge-recursive.c to follow suit and end up with an immediate evaluation
and fix-it-up-as-you-go design. Some things like directory/file
conflicts are not well representable in the index data structure, and
required special extra code to handle. But then when it was discovered
that rename/delete conflicts could also be involved in directory/file
conflicts, the special directory/file conflict handling code had to be
copied to the rename/delete codepath. ...and then it had to be copied
for modify/delete, and for rename/rename(1to2) conflicts, ...and yet it
still missed some. Further, when it was discovered that there were also
file/submodule conflicts and submodule/directory conflicts, we needed to
copy the special submodule handling code to all the special cases
throughout the codebase.
And then it was discovered that our handling of directory/file conflicts
was suboptimal because it would create untracked files to store the
contents of the conflicting file, which would not be cleaned up if
someone were to run a 'git merge --abort' or 'git rebase --abort'. It
was also difficult or scary to try to add or remove the index entries
corresponding to these files given the directory/file conflict in the
index. But changing merge-recursive.c to handle these correctly was a
royal pain because there were so many sites in the code with similar but
not identical code for handling directory/file/submodule conflicts that
would all need to be updated.
I have worked hard to push all directory/file/submodule conflict
handling in merge-ort through a single codepath, and avoid creating
untracked files for storing tracked content (it does record things at
alternate paths, but makes sure they have higher-order stages in the
index).
Since updating merge-recursive is too much work and we don't want to
destabilize it, instead update the testsuite to have different
expectations for relevant directory/file/submodule conflict tests.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-26 17:01:37 +00:00
|
|
|
test_path_is_file one &&
|
|
|
|
test_path_is_file two &&
|
|
|
|
test "other" = $(cat one) &&
|
|
|
|
test "stuff" = $(cat two)
|
|
|
|
'
|
|
|
|
else
|
|
|
|
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 &&
|
|
|
|
|
2021-07-04 05:46:12 +00:00
|
|
|
test_stdout_line_count = 2 git ls-files -u &&
|
|
|
|
test_stdout_line_count = 1 git ls-files -u one &&
|
|
|
|
test_stdout_line_count = 1 git ls-files -u two &&
|
merge tests: expect improved directory/file conflict handling in ort
merge-recursive.c is built on the idea of running unpack_trees() and
then "doing minor touch-ups" to get the result. Unfortunately,
unpack_trees() was run in an update-as-it-goes mode, leading
merge-recursive.c to follow suit and end up with an immediate evaluation
and fix-it-up-as-you-go design. Some things like directory/file
conflicts are not well representable in the index data structure, and
required special extra code to handle. But then when it was discovered
that rename/delete conflicts could also be involved in directory/file
conflicts, the special directory/file conflict handling code had to be
copied to the rename/delete codepath. ...and then it had to be copied
for modify/delete, and for rename/rename(1to2) conflicts, ...and yet it
still missed some. Further, when it was discovered that there were also
file/submodule conflicts and submodule/directory conflicts, we needed to
copy the special submodule handling code to all the special cases
throughout the codebase.
And then it was discovered that our handling of directory/file conflicts
was suboptimal because it would create untracked files to store the
contents of the conflicting file, which would not be cleaned up if
someone were to run a 'git merge --abort' or 'git rebase --abort'. It
was also difficult or scary to try to add or remove the index entries
corresponding to these files given the directory/file conflict in the
index. But changing merge-recursive.c to handle these correctly was a
royal pain because there were so many sites in the code with similar but
not identical code for handling directory/file/submodule conflicts that
would all need to be updated.
I have worked hard to push all directory/file/submodule conflict
handling in merge-ort through a single codepath, and avoid creating
untracked files for storing tracked content (it does record things at
alternate paths, but makes sure they have higher-order stages in the
index).
Since updating merge-recursive is too much work and we don't want to
destabilize it, instead update the testsuite to have different
expectations for relevant directory/file/submodule conflict tests.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-26 17:01:37 +00:00
|
|
|
|
|
|
|
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)
|
|
|
|
'
|
|
|
|
fi
|
2010-09-20 08:28:40 +00:00
|
|
|
|
|
|
|
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 &&
|
|
|
|
|
merge tests: expect improved directory/file conflict handling in ort
merge-recursive.c is built on the idea of running unpack_trees() and
then "doing minor touch-ups" to get the result. Unfortunately,
unpack_trees() was run in an update-as-it-goes mode, leading
merge-recursive.c to follow suit and end up with an immediate evaluation
and fix-it-up-as-you-go design. Some things like directory/file
conflicts are not well representable in the index data structure, and
required special extra code to handle. But then when it was discovered
that rename/delete conflicts could also be involved in directory/file
conflicts, the special directory/file conflict handling code had to be
copied to the rename/delete codepath. ...and then it had to be copied
for modify/delete, and for rename/rename(1to2) conflicts, ...and yet it
still missed some. Further, when it was discovered that there were also
file/submodule conflicts and submodule/directory conflicts, we needed to
copy the special submodule handling code to all the special cases
throughout the codebase.
And then it was discovered that our handling of directory/file conflicts
was suboptimal because it would create untracked files to store the
contents of the conflicting file, which would not be cleaned up if
someone were to run a 'git merge --abort' or 'git rebase --abort'. It
was also difficult or scary to try to add or remove the index entries
corresponding to these files given the directory/file conflict in the
index. But changing merge-recursive.c to handle these correctly was a
royal pain because there were so many sites in the code with similar but
not identical code for handling directory/file/submodule conflicts that
would all need to be updated.
I have worked hard to push all directory/file/submodule conflict
handling in merge-ort through a single codepath, and avoid creating
untracked files for storing tracked content (it does record things at
alternate paths, but makes sure they have higher-order stages in the
index).
Since updating merge-recursive is too much work and we don't want to
destabilize it, instead update the testsuite to have different
expectations for relevant directory/file/submodule conflict tests.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-26 17:01:37 +00:00
|
|
|
if test "$GIT_TEST_MERGE_ALGORITHM" = ort
|
|
|
|
then
|
2021-07-04 05:46:12 +00:00
|
|
|
test_stdout_line_count = 4 git ls-files -u &&
|
|
|
|
test_stdout_line_count = 2 git ls-files -u one &&
|
|
|
|
test_stdout_line_count = 2 git ls-files -u two
|
merge tests: expect improved directory/file conflict handling in ort
merge-recursive.c is built on the idea of running unpack_trees() and
then "doing minor touch-ups" to get the result. Unfortunately,
unpack_trees() was run in an update-as-it-goes mode, leading
merge-recursive.c to follow suit and end up with an immediate evaluation
and fix-it-up-as-you-go design. Some things like directory/file
conflicts are not well representable in the index data structure, and
required special extra code to handle. But then when it was discovered
that rename/delete conflicts could also be involved in directory/file
conflicts, the special directory/file conflict handling code had to be
copied to the rename/delete codepath. ...and then it had to be copied
for modify/delete, and for rename/rename(1to2) conflicts, ...and yet it
still missed some. Further, when it was discovered that there were also
file/submodule conflicts and submodule/directory conflicts, we needed to
copy the special submodule handling code to all the special cases
throughout the codebase.
And then it was discovered that our handling of directory/file conflicts
was suboptimal because it would create untracked files to store the
contents of the conflicting file, which would not be cleaned up if
someone were to run a 'git merge --abort' or 'git rebase --abort'. It
was also difficult or scary to try to add or remove the index entries
corresponding to these files given the directory/file conflict in the
index. But changing merge-recursive.c to handle these correctly was a
royal pain because there were so many sites in the code with similar but
not identical code for handling directory/file/submodule conflicts that
would all need to be updated.
I have worked hard to push all directory/file/submodule conflict
handling in merge-ort through a single codepath, and avoid creating
untracked files for storing tracked content (it does record things at
alternate paths, but makes sure they have higher-order stages in the
index).
Since updating merge-recursive is too much work and we don't want to
destabilize it, instead update the testsuite to have different
expectations for relevant directory/file/submodule conflict tests.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-26 17:01:37 +00:00
|
|
|
else
|
2021-07-04 05:46:12 +00:00
|
|
|
test_stdout_line_count = 2 git ls-files -u &&
|
|
|
|
test_stdout_line_count = 1 git ls-files -u one &&
|
|
|
|
test_stdout_line_count = 1 git ls-files -u two
|
merge tests: expect improved directory/file conflict handling in ort
merge-recursive.c is built on the idea of running unpack_trees() and
then "doing minor touch-ups" to get the result. Unfortunately,
unpack_trees() was run in an update-as-it-goes mode, leading
merge-recursive.c to follow suit and end up with an immediate evaluation
and fix-it-up-as-you-go design. Some things like directory/file
conflicts are not well representable in the index data structure, and
required special extra code to handle. But then when it was discovered
that rename/delete conflicts could also be involved in directory/file
conflicts, the special directory/file conflict handling code had to be
copied to the rename/delete codepath. ...and then it had to be copied
for modify/delete, and for rename/rename(1to2) conflicts, ...and yet it
still missed some. Further, when it was discovered that there were also
file/submodule conflicts and submodule/directory conflicts, we needed to
copy the special submodule handling code to all the special cases
throughout the codebase.
And then it was discovered that our handling of directory/file conflicts
was suboptimal because it would create untracked files to store the
contents of the conflicting file, which would not be cleaned up if
someone were to run a 'git merge --abort' or 'git rebase --abort'. It
was also difficult or scary to try to add or remove the index entries
corresponding to these files given the directory/file conflict in the
index. But changing merge-recursive.c to handle these correctly was a
royal pain because there were so many sites in the code with similar but
not identical code for handling directory/file/submodule conflicts that
would all need to be updated.
I have worked hard to push all directory/file/submodule conflict
handling in merge-ort through a single codepath, and avoid creating
untracked files for storing tracked content (it does record things at
alternate paths, but makes sure they have higher-order stages in the
index).
Since updating merge-recursive is too much work and we don't want to
destabilize it, instead update the testsuite to have different
expectations for relevant directory/file/submodule conflict tests.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-26 17:01:37 +00:00
|
|
|
fi &&
|
2010-09-20 08:28:40 +00:00
|
|
|
|
|
|
|
test_must_fail git diff --quiet &&
|
|
|
|
|
2010-11-08 21:29:26 +00:00
|
|
|
test 3 -eq $(find . | grep -v .git | wc -l) &&
|
2010-09-20 08:28:40 +00:00
|
|
|
|
2020-02-27 00:14:21 +00:00
|
|
|
test_path_is_file one &&
|
|
|
|
test_path_is_file two &&
|
2010-09-20 08:28:40 +00:00
|
|
|
test "other" = $(cat one) &&
|
|
|
|
test "stuff" = $(cat two)
|
|
|
|
'
|
|
|
|
|
2010-09-20 08:28:41 +00:00
|
|
|
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 &&
|
2013-09-04 22:28:45 +00:00
|
|
|
git commit -m "Common commit" &&
|
2010-09-20 08:28:41 +00:00
|
|
|
|
|
|
|
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"
|
|
|
|
'
|
|
|
|
|
2010-09-20 08:29:00 +00:00
|
|
|
test_expect_success 'check handling of differently renamed file with D/F conflicts' '
|
2010-09-20 08:28:41 +00:00
|
|
|
git checkout -q first-rename^0 &&
|
|
|
|
test_must_fail git merge --strategy=recursive second-rename &&
|
|
|
|
|
merge tests: expect improved directory/file conflict handling in ort
merge-recursive.c is built on the idea of running unpack_trees() and
then "doing minor touch-ups" to get the result. Unfortunately,
unpack_trees() was run in an update-as-it-goes mode, leading
merge-recursive.c to follow suit and end up with an immediate evaluation
and fix-it-up-as-you-go design. Some things like directory/file
conflicts are not well representable in the index data structure, and
required special extra code to handle. But then when it was discovered
that rename/delete conflicts could also be involved in directory/file
conflicts, the special directory/file conflict handling code had to be
copied to the rename/delete codepath. ...and then it had to be copied
for modify/delete, and for rename/rename(1to2) conflicts, ...and yet it
still missed some. Further, when it was discovered that there were also
file/submodule conflicts and submodule/directory conflicts, we needed to
copy the special submodule handling code to all the special cases
throughout the codebase.
And then it was discovered that our handling of directory/file conflicts
was suboptimal because it would create untracked files to store the
contents of the conflicting file, which would not be cleaned up if
someone were to run a 'git merge --abort' or 'git rebase --abort'. It
was also difficult or scary to try to add or remove the index entries
corresponding to these files given the directory/file conflict in the
index. But changing merge-recursive.c to handle these correctly was a
royal pain because there were so many sites in the code with similar but
not identical code for handling directory/file/submodule conflicts that
would all need to be updated.
I have worked hard to push all directory/file/submodule conflict
handling in merge-ort through a single codepath, and avoid creating
untracked files for storing tracked content (it does record things at
alternate paths, but makes sure they have higher-order stages in the
index).
Since updating merge-recursive is too much work and we don't want to
destabilize it, instead update the testsuite to have different
expectations for relevant directory/file/submodule conflict tests.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-26 17:01:37 +00:00
|
|
|
if test "$GIT_TEST_MERGE_ALGORITHM" = ort
|
|
|
|
then
|
2021-07-04 05:46:12 +00:00
|
|
|
test_stdout_line_count = 5 git ls-files -s &&
|
|
|
|
test_stdout_line_count = 3 git ls-files -u &&
|
|
|
|
test_stdout_line_count = 1 git ls-files -u one~HEAD &&
|
|
|
|
test_stdout_line_count = 1 git ls-files -u two~second-rename &&
|
|
|
|
test_stdout_line_count = 1 git ls-files -u original &&
|
|
|
|
test_stdout_line_count = 0 git ls-files -o
|
merge tests: expect improved directory/file conflict handling in ort
merge-recursive.c is built on the idea of running unpack_trees() and
then "doing minor touch-ups" to get the result. Unfortunately,
unpack_trees() was run in an update-as-it-goes mode, leading
merge-recursive.c to follow suit and end up with an immediate evaluation
and fix-it-up-as-you-go design. Some things like directory/file
conflicts are not well representable in the index data structure, and
required special extra code to handle. But then when it was discovered
that rename/delete conflicts could also be involved in directory/file
conflicts, the special directory/file conflict handling code had to be
copied to the rename/delete codepath. ...and then it had to be copied
for modify/delete, and for rename/rename(1to2) conflicts, ...and yet it
still missed some. Further, when it was discovered that there were also
file/submodule conflicts and submodule/directory conflicts, we needed to
copy the special submodule handling code to all the special cases
throughout the codebase.
And then it was discovered that our handling of directory/file conflicts
was suboptimal because it would create untracked files to store the
contents of the conflicting file, which would not be cleaned up if
someone were to run a 'git merge --abort' or 'git rebase --abort'. It
was also difficult or scary to try to add or remove the index entries
corresponding to these files given the directory/file conflict in the
index. But changing merge-recursive.c to handle these correctly was a
royal pain because there were so many sites in the code with similar but
not identical code for handling directory/file/submodule conflicts that
would all need to be updated.
I have worked hard to push all directory/file/submodule conflict
handling in merge-ort through a single codepath, and avoid creating
untracked files for storing tracked content (it does record things at
alternate paths, but makes sure they have higher-order stages in the
index).
Since updating merge-recursive is too much work and we don't want to
destabilize it, instead update the testsuite to have different
expectations for relevant directory/file/submodule conflict tests.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-26 17:01:37 +00:00
|
|
|
else
|
2021-07-04 05:46:12 +00:00
|
|
|
test_stdout_line_count = 5 git ls-files -s &&
|
|
|
|
test_stdout_line_count = 3 git ls-files -u &&
|
|
|
|
test_stdout_line_count = 1 git ls-files -u one &&
|
|
|
|
test_stdout_line_count = 1 git ls-files -u two &&
|
|
|
|
test_stdout_line_count = 1 git ls-files -u original &&
|
|
|
|
test_stdout_line_count = 2 git ls-files -o
|
merge tests: expect improved directory/file conflict handling in ort
merge-recursive.c is built on the idea of running unpack_trees() and
then "doing minor touch-ups" to get the result. Unfortunately,
unpack_trees() was run in an update-as-it-goes mode, leading
merge-recursive.c to follow suit and end up with an immediate evaluation
and fix-it-up-as-you-go design. Some things like directory/file
conflicts are not well representable in the index data structure, and
required special extra code to handle. But then when it was discovered
that rename/delete conflicts could also be involved in directory/file
conflicts, the special directory/file conflict handling code had to be
copied to the rename/delete codepath. ...and then it had to be copied
for modify/delete, and for rename/rename(1to2) conflicts, ...and yet it
still missed some. Further, when it was discovered that there were also
file/submodule conflicts and submodule/directory conflicts, we needed to
copy the special submodule handling code to all the special cases
throughout the codebase.
And then it was discovered that our handling of directory/file conflicts
was suboptimal because it would create untracked files to store the
contents of the conflicting file, which would not be cleaned up if
someone were to run a 'git merge --abort' or 'git rebase --abort'. It
was also difficult or scary to try to add or remove the index entries
corresponding to these files given the directory/file conflict in the
index. But changing merge-recursive.c to handle these correctly was a
royal pain because there were so many sites in the code with similar but
not identical code for handling directory/file/submodule conflicts that
would all need to be updated.
I have worked hard to push all directory/file/submodule conflict
handling in merge-ort through a single codepath, and avoid creating
untracked files for storing tracked content (it does record things at
alternate paths, but makes sure they have higher-order stages in the
index).
Since updating merge-recursive is too much work and we don't want to
destabilize it, instead update the testsuite to have different
expectations for relevant directory/file/submodule conflict tests.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-26 17:01:37 +00:00
|
|
|
fi &&
|
2010-09-20 08:28:41 +00:00
|
|
|
|
2020-02-27 00:14:21 +00:00
|
|
|
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
|
2010-09-20 08:28:41 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
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 &&
|
2013-09-04 22:28:45 +00:00
|
|
|
git commit -m "Common commit" &&
|
2010-09-20 08:28:41 +00:00
|
|
|
|
|
|
|
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"
|
|
|
|
'
|
|
|
|
|
2010-09-20 08:29:06 +00:00
|
|
|
test_expect_success 'check handling of differently renamed file with D/F conflicts' '
|
2010-09-20 08:28:41 +00:00
|
|
|
git checkout -q first-rename-redo^0 &&
|
|
|
|
test_must_fail git merge --strategy=recursive second-rename-redo &&
|
|
|
|
|
2021-07-04 05:46:12 +00:00
|
|
|
test_stdout_line_count = 3 git ls-files -u &&
|
|
|
|
test_stdout_line_count = 1 git ls-files -u one &&
|
|
|
|
test_stdout_line_count = 1 git ls-files -u two &&
|
|
|
|
test_stdout_line_count = 1 git ls-files -u original &&
|
|
|
|
test_stdout_line_count = 0 git ls-files -o &&
|
2010-09-20 08:28:41 +00:00
|
|
|
|
2020-02-27 00:14:21 +00:00
|
|
|
test_path_is_file one &&
|
|
|
|
test_path_is_file two &&
|
|
|
|
test_path_is_missing original
|
2010-09-20 08:28:41 +00:00
|
|
|
'
|
|
|
|
|
2011-08-12 05:19:47 +00:00
|
|
|
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 &&
|
2013-09-04 22:28:45 +00:00
|
|
|
git commit -m "Common commit" &&
|
2011-08-12 05:19:47 +00:00
|
|
|
|
|
|
|
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' '
|
2011-08-12 05:19:47 +00:00
|
|
|
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 &&
|
2011-08-12 05:19:47 +00:00
|
|
|
git merge merge-branch-1 &&
|
2018-04-25 04:29:00 +00:00
|
|
|
test-tool chmtime --get rename >actual &&
|
2011-08-12 05:19:47 +00:00
|
|
|
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 &&
|
2013-09-04 22:28:45 +00:00
|
|
|
git commit -m "Common commit" &&
|
2011-08-12 05:19:47 +00:00
|
|
|
|
|
|
|
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' '
|
2011-08-12 05:19:47 +00:00
|
|
|
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 &&
|
2011-08-12 05:19:47 +00:00
|
|
|
git merge merge-branch-2 &&
|
2018-04-25 04:29:00 +00:00
|
|
|
test-tool chmtime --get df >actual &&
|
2011-08-12 05:19:47 +00:00
|
|
|
test_cmp expect actual # "df" should have stayed intact
|
|
|
|
'
|
|
|
|
|
2011-08-12 05:20:26 +00:00
|
|
|
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 &&
|
|
|
|
|
2015-03-20 10:07:15 +00:00
|
|
|
git checkout -b side &&
|
2011-08-12 05:20:26 +00:00
|
|
|
git rm -rf df &&
|
|
|
|
git commit -mB &&
|
|
|
|
|
2020-11-18 23:44:38 +00:00
|
|
|
git checkout main &&
|
2011-08-12 05:20:26 +00:00
|
|
|
git rm -rf df &&
|
|
|
|
echo bla >df &&
|
|
|
|
git add -A &&
|
|
|
|
git commit -m "Add a newfile"
|
|
|
|
'
|
|
|
|
|
2011-08-12 05:20:27 +00:00
|
|
|
test_expect_success 'avoid unnecessary update, dir->(file,nothing)' '
|
2020-11-18 23:44:38 +00:00
|
|
|
git checkout -q main^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 &&
|
2011-08-12 05:20:26 +00:00
|
|
|
git merge side &&
|
2018-04-25 04:29:00 +00:00
|
|
|
test-tool chmtime --get df >actual &&
|
2011-08-12 05:20:26 +00:00
|
|
|
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 &&
|
|
|
|
|
2015-03-20 10:07:15 +00:00
|
|
|
git checkout -b side &&
|
2011-08-12 05:20:26 +00:00
|
|
|
git rm -f file &&
|
|
|
|
git commit -m "Delete file" &&
|
|
|
|
|
2020-11-18 23:44:38 +00:00
|
|
|
git checkout main &&
|
2011-08-12 05:20:26 +00:00
|
|
|
echo bla >file &&
|
|
|
|
git add -A &&
|
|
|
|
git commit -m "Modify file"
|
|
|
|
'
|
|
|
|
|
2011-08-12 05:20:27 +00:00
|
|
|
test_expect_success 'avoid unnecessary update, modify/delete' '
|
2020-11-18 23:44:38 +00:00
|
|
|
git checkout -q main^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 &&
|
2011-08-12 05:20:26 +00:00
|
|
|
test_must_fail git merge side &&
|
2018-04-25 04:29:00 +00:00
|
|
|
test-tool chmtime --get file >actual &&
|
2011-08-12 05:20:26 +00:00
|
|
|
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 &&
|
|
|
|
|
2015-03-20 10:07:15 +00:00
|
|
|
git checkout -b side &&
|
2011-08-12 05:20:26 +00:00
|
|
|
cp file newfile &&
|
|
|
|
git add -A &&
|
|
|
|
git commit -m "Add file copy" &&
|
|
|
|
|
2020-11-18 23:44:38 +00:00
|
|
|
git checkout main &&
|
2011-08-12 05:20:26 +00:00
|
|
|
git mv file newfile &&
|
|
|
|
git commit -m "Rename file"
|
|
|
|
'
|
|
|
|
|
2011-08-12 05:20:27 +00:00
|
|
|
test_expect_success 'avoid unnecessary update, rename/add-dest' '
|
2020-11-18 23:44:38 +00:00
|
|
|
git checkout -q main^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 &&
|
2011-08-12 05:20:26 +00:00
|
|
|
git merge side &&
|
2018-04-25 04:29:00 +00:00
|
|
|
test-tool chmtime --get newfile >actual &&
|
2011-08-12 05:20:26 +00:00
|
|
|
test_cmp expect actual # "file" should have stayed intact
|
|
|
|
'
|
|
|
|
|
2011-08-12 05:19:48 +00:00
|
|
|
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 &&
|
|
|
|
|
2021-07-04 05:46:12 +00:00
|
|
|
test_stdout_line_count = 1 git ls-files -s &&
|
|
|
|
test_stdout_line_count = 0 git ls-files -o &&
|
|
|
|
newhash=$(git rev-parse HEAD:renamed_file) &&
|
|
|
|
oldhash=$(git rev-parse HEAD~1:file) &&
|
|
|
|
test $newhash = $oldhash
|
2011-08-12 05:19:48 +00:00
|
|
|
'
|
|
|
|
|
2011-08-12 05:20:09 +00:00
|
|
|
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 &&
|
|
|
|
|
2020-11-18 23:44:38 +00:00
|
|
|
git checkout main &&
|
2011-08-12 05:20:09 +00:00
|
|
|
echo 8.5 >>original_file &&
|
|
|
|
git add original_file &&
|
|
|
|
git commit -mC
|
|
|
|
'
|
|
|
|
|
2020-11-18 23:44:38 +00:00
|
|
|
test_expect_success 'merge main into rename has correct extended markers' '
|
2011-08-12 05:20:09 +00:00
|
|
|
git checkout rename^0 &&
|
2020-11-18 23:44:38 +00:00
|
|
|
test_must_fail git merge -s recursive main^0 &&
|
2020-02-27 00:14:20 +00:00
|
|
|
|
|
|
|
cat >expected <<-\EOF &&
|
|
|
|
1
|
|
|
|
2
|
|
|
|
3
|
|
|
|
4
|
|
|
|
5
|
|
|
|
6
|
|
|
|
7
|
|
|
|
8
|
|
|
|
<<<<<<< HEAD:renamed_file
|
|
|
|
9
|
|
|
|
=======
|
|
|
|
8.5
|
2020-11-18 23:44:38 +00:00
|
|
|
>>>>>>> main^0:original_file
|
2020-02-27 00:14:20 +00:00
|
|
|
EOF
|
2011-08-12 05:20:09 +00:00
|
|
|
test_cmp expected renamed_file
|
|
|
|
'
|
|
|
|
|
2020-11-18 23:44:38 +00:00
|
|
|
test_expect_success 'merge rename into main has correct extended markers' '
|
2011-08-12 05:20:09 +00:00
|
|
|
git reset --hard &&
|
2020-11-18 23:44:38 +00:00
|
|
|
git checkout main^0 &&
|
2011-08-12 05:20:09 +00:00
|
|
|
test_must_fail git merge -s recursive rename^0 &&
|
2020-02-27 00:14:20 +00:00
|
|
|
|
|
|
|
cat >expected <<-\EOF &&
|
|
|
|
1
|
|
|
|
2
|
|
|
|
3
|
|
|
|
4
|
|
|
|
5
|
|
|
|
6
|
|
|
|
7
|
|
|
|
8
|
|
|
|
<<<<<<< HEAD:original_file
|
|
|
|
8.5
|
|
|
|
=======
|
|
|
|
9
|
|
|
|
>>>>>>> rename^0:renamed_file
|
|
|
|
EOF
|
2011-08-12 05:20:09 +00:00
|
|
|
test_cmp expected renamed_file
|
|
|
|
'
|
|
|
|
|
2011-08-12 05:20:24 +00:00
|
|
|
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 &&
|
|
|
|
|
2020-11-18 23:44:38 +00:00
|
|
|
git checkout main &&
|
2011-08-12 05:20:24 +00:00
|
|
|
git rm original_file &&
|
|
|
|
git commit -mC
|
|
|
|
'
|
|
|
|
|
2011-08-12 05:20:25 +00:00
|
|
|
test_expect_success 'no spurious "refusing to lose untracked" message' '
|
2020-11-18 23:44:38 +00:00
|
|
|
git checkout main^0 &&
|
2011-08-12 05:20:24 +00:00
|
|
|
test_must_fail git merge rename^0 2>errors.txt &&
|
|
|
|
! grep "refusing to lose untracked file" errors.txt
|
|
|
|
'
|
|
|
|
|
2012-03-22 22:52:24 +00:00
|
|
|
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 &&
|
2018-07-27 17:48:11 +00:00
|
|
|
test_must_be_empty empty2
|
2012-03-22 22:52:24 +00:00
|
|
|
'
|
|
|
|
|
2005-12-11 20:44:46 +00:00
|
|
|
test_done
|