Here's a little script that reproduces the problem:
-----
#!/bin/bash
set -e
if [ -e git-merge-problem ]; then
echo "'git-merge-problem' exists, not running test!"
exit 1
fi
mkdir git-merge-problem
cd git-merge-problem
git init
echo "first line" > myfile
echo "second line" >> myfile
echo "" >> myfile
echo "next to last line" >> myfile
echo "final line" >> myfile
git add myfile
git commit -m 'initial commit of myfile'
git branch other
sed -i -e 's/second line/this line is in the context of the crucial patch/' myfile
git add myfile
git commit -m 'change context for crucial patch'
sed -i -e 's/^$/\nthis line is added only once, but in two branches\n/' myfile
git add myfile
git commit -m 'add a line'
git tag add-a-line
git checkout other
git cherry-pick -x add-a-line
git checkout master
git merge other
NUM_LINES=$(grep 'added only once' myfile | wc -l)
if [ $NUM_LINES -eq 2 ]; then
echo "FAIL! the merge added the line twice"
cat myfile
exit 1
elif [ $NUM_LINES -ne 1 ]; then
echo "FAIL! the merge added the line a strange number of times ($NUM_LINES)"
exit 1
fi
echo "PASS! the merge added the line just once!"
exit 0
-----
On May 11, 2012, at 20:25 , Illia Bobyr wrote:
> On 5/11/2012 5:05 PM, Sebastian Kuzminsky wrote:
>> On 05/11/2012 05:57 PM, Michael Witten wrote:
>>> On Fri, 11 May 2012 16:25:29 -0600, Sebastian Kuzminsky wrote:
>>>
>>>> The simplified repo is here if anyone wants to inspect it:
>>>> https://github.com/SebKuzminsky/merge-problem
>> ...
>>
>>> In other words, rather than burdening people with the task of
>>> constructing a mental picture of what you have done, you should
>>> show them as directly and precisely as possible; in this way,
>>> people can go about the business of discussing your issue much
>>> more quickly and, most importantly, PRECISELY.
>>>
>>
>> Ah, I had intended the extremely tiny git repo I linked to to provide
>> the info in the most concise way possible. The surprising behaviour
>> happened at the final commit in the repo, which was made by 'git merge
>> other'.
>>
>> I can email a list of commands to reproduce the issue later tonight if
>> that would make anything clearer.
>
> The repository you provided is actually quite simple and clear, though I
> have no idea why this might be happening. Or if it is an expected behavior.
>
> At the same time if you provide a list of command if someone will be
> fixing this they may server as an automated test. Git has a lot of them.
>
> --
> Illia Bobyr
--
Sebastian Kuzminsky
--
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