surprising behavior from merge

surprising behavior from merge

[Sebastian Kuzminsky]

Hi folks, I just ran in to a strange behavior with git merge.

Things start out with two branches (let's call them 'master' and 'other') pointing at a particular commit.  In master I commit a small one-line change, then make a second commit that adds some stuff just after the line changed in the previous commit.  In the other branch, i cherry-pick the second commit from master (the one that adds the new stuff).  The cherry-pick succeeds, despite the fuzzy context.  So far, so good.

Next I try to merge other into master.  I expected it to notice there was nothing to do and leave the master tree unchanged, but it applied the "add new stuff" patch to master (even though that patch is already in master) and made a commit from that.  So it silently did the wrong thing, and now the file contains two copies of stuff I added.

That is a simplified version of what happened, in my real repo there were several (unrelated and unimportant) commits on both master and the other branch.  When the surprising double-add happened, i simplified the repo to remove distractions.  The simplified repo is here if anyone wants to inspect it:  https://github.com/SebKuzminsky/merge-problem


-- 
Sebastian Kuzminsky

Re: surprising behavior from merge

[Michael Witten]

On Fri, 11 May 2012 16:25:29 -0600, Sebastian Kuzminsky wrote:

> Hi folks, I just ran in to a strange behavior with git merge.
>
> Things start out with two branches (let's call them 'master' and
> 'other') pointing at a particular commit. In master I commit a
> small one-line change, then make a second commit that adds some
> stuff just after the line changed in the previous commit. In the
> other branch, i cherry-pick the second commit from master (the
> one that adds the new stuff). The cherry-pick succeeds, despite
> the fuzzy context. So far, so good.
>
> Next I try to merge other into master. I expected it to notice
> there was nothing to do and leave the master tree unchanged,
> but it applied the "add new stuff" patch to master (even though
> that patch is already in master) and made a commit from that. So
> it silently did the wrong thing, and now the file contains two
> copies of stuff I added.
>
> That is a simplified version of what happened, in my real repo
> there were several (unrelated and unimportant) commits on both
> master and the other branch. When the surprising double-add
> happened, i simplified the repo to remove distractions.
> The simplified repo is here if anyone wants to inspect it:
> https://github.com/SebKuzminsky/merge-problem

It would obviously be helpful to supply:

  * Explicit commands that anyone on the list can try and discuss.
    For example:

      git init repo
      cd repo
      echo a  > a; git add a; git commit -m 'small one-line change'
      echo b >> a; git commit -am 'adds some stuff after'
      ...

  * Expected behavior from those commands.

  * Actual behavior from those commands.

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.

Sincerely,
Michael Witten

Re: surprising behavior from merge

[Sebastian Kuzminsky]

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.


-- 
Sebastian Kuzminsky

Re: surprising behavior from merge

[Illia Bobyr]

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

Re: surprising behavior from merge

[Sebastian Kuzminsky]

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