Johannes Schindelin [off-list ref] writes:
this test succeeds consistently on the machine where I tested it
originally, but fails on another of my machines, but only when run without
"-v". Very annoying. I will not have time to investigate until Monday,
though.
There seem to be cases where stage #1 contains blob 'B' or 'A'
or nothing depending on something totally random. Ring a bell?
This script tests a complicated merge, where _all_ files conflict. In
these circumstances, the ordering of the commits -- which is affected
not by the timestamps in the commit message -- becomes a deciding factor
of the merge result.
Signed-off-by: Johannes Schindelin <redacted>
---
On Sat, 9 Dec 2006, Junio C Hamano wrote:
> There seem to be cases where stage #1 contains blob 'B' or 'A'
> or nothing depending on something totally random. Ring a bell?
This patch fixes it..
Depending on the order, an add/add conflict _removes_ the file
from the index, and as a consequence stage 1 is missing in the
final merge (which still fails, because the return value of the
previous merge is remembered).
How about this: if there is an add/add conflict, we treat it as
if there _was_ an empty file, and we let the shiny new xdl_merge()
find the _true_ conflicts, _instead of_ removing the file from
the index, adding both files with different "~blabla" markers
appended to their file names to the working directory.
Hmm?
t/t6024-recursive-merge.sh | 20 +++++++++++---------
1 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/t/t6024-recursive-merge.sh b/t/t6024-recursive-merge.sh
index 5f821fb..9416c27 100644
--- a/t/t6024-recursive-merge.sh
+++ b/t/t6024-recursive-merge.sh
@@ -11,54 +11,56 @@ test_description='Test merge without common ancestors'
# X \
# 2 - C - E - G
+export GIT_COMMITTER_DATE="2006-12-12 23:28:00 +0100"
echo 1 > a1
git add a1
-git commit -m 1 a1
+GIT_AUTHOR_DATE="2006-12-12 23:00:00" git commit -m 1 a1
git checkout -b A master
echo A > a1
-git commit -m A a1
+GIT_AUTHOR_DATE="2006-12-12 23:00:01" git commit -m A a1
git checkout -b B master
echo B > a1
-git commit -m B a1
+GIT_AUTHOR_DATE="2006-12-12 23:00:02" git commit -m B a1
git checkout -b D A
git-rev-parse B > .git/MERGE_HEAD
echo D > a1
git update-index a1
-git commit -m D
+GIT_AUTHOR_DATE="2006-12-12 23:00:03" git commit -m D
git symbolic-ref HEAD refs/heads/other
echo 2 > a1
-git commit -m 2 a1
+GIT_AUTHOR_DATE="2006-12-12 23:00:04" git commit -m 2 a1
git checkout -b C
echo C > a1
-git commit -m C a1
+GIT_AUTHOR_DATE="2006-12-12 23:00:05" git commit -m C a1
git checkout -b E C
git-rev-parse B > .git/MERGE_HEAD
echo E > a1
git update-index a1
-git commit -m E
+GIT_AUTHOR_DATE="2006-12-12 23:00:06" git commit -m E
git checkout -b G E
git-rev-parse A > .git/MERGE_HEAD
echo G > a1
git update-index a1
-git commit -m G
+GIT_AUTHOR_DATE="2006-12-12 23:00:07" git commit -m G
git checkout -b F D
git-rev-parse C > .git/MERGE_HEAD
echo F > a1
git update-index a1
-git commit -m F
+GIT_AUTHOR_DATE="2006-12-12 23:00:08" git commit -m F
test_expect_failure "combined merge conflicts" "git merge -m final G"
git ls-files --stage > out
cat > expect << EOF
+100644 f70f10e4db19068f79bc43844b49f3eece45c4e8 1 a1
100644 cf84443e49e1b366fac938711ddf4be2d4d1d9e9 2 a1
100644 fd7923529855d0b274795ae3349c5e0438333979 3 a1
EOF
--
1.4.4.2.g473fa0-dirty
Hi,
On Sat, 9 Dec 2006, Junio C Hamano wrote:
Johannes Schindelin [off-list ref] writes:
quoted
this test succeeds consistently on the machine where I tested it
originally, but fails on another of my machines, but only when run without
"-v". Very annoying. I will not have time to investigate until Monday,
though.
There seem to be cases where stage #1 contains blob 'B' or 'A'
or nothing depending on something totally random. Ring a bell?
Not at all.
It seems that one merge is conflicting on "a1", and not storing _anything_
in the resulting (unclean) tree. So, there is no stage 1.
However, I also saw that something is left in stage 1 on the box where the
problem arises. Tomorrow.
Ciao,
Dscho