Johannes Sixt <j6t@xxxxxxxx> writes:
> I did encounter a case where the same resolution would apply to all
> conflicts that have the same conflict hash, so it's not quite what you
> talk about. But not all conflicts were automatically resolved. I haven't
> yet analyzed what happened - it could just be that the xdl_merge call
> fails due to the differences in the text immediately outside the
> conflict markers.
Actually it is _very_ easy to fool rerere to do something totally
unexpected, and I have been thinking about using the similarity comparison
algorithm on the region outside the conflicted area between preimage and
thisimage and reject use of rerere.
Try this in an empty directory.
-- >8 --
#!/bin/sh
git init
create_numbers () {
for n in 0 1 2 3 4 "$1" 5 6 7 8 9
do
echo $n
done >numbers.txt
}
create_letters () {
for l in a b c d e "$1" f g h i j
do
echo $l
done >letters.txt
}
create_files () {
create_numbers "$1"
create_letters "$1"
}
create_files ""
git add numbers.txt letters.txt
git commit -m initial
git branch side
create_files "+"
git commit -a -m master
git checkout side
create_files "-"
git commit -a -m side
mkdir -p .git/rr-cache
# On this history we changed an empty line to +; merge
# with another history that changed it to -
git checkout master^0
git merge side
# The above should have conflicted. The resolution is to '='
create_numbers "="
git rerere
git rerere status
git rerere diff
cat numbers.txt
cat letters.txt
-- 8< --
Now, immediately after this sequence, rerere will give you an disaster.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html