{"thread":{"id":"30513","subject":"surprising behavior from merge","startedAt":"2012-05-11T22:25:29Z","lastAt":"2012-05-14T18:14:21Z","messageCount":5,"participants":["Sebastian Kuzminsky","Michael Witten","Illia Bobyr"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"191423","messageId":"9A9AD20F-B316-4DC1-8C6A-E0FC6ED80A61@highlab.com","threadId":"30513","inReplyTo":null,"subject":"surprising behavior from merge","fromName":"Sebastian Kuzminsky","fromEmail":"seb@highlab.com","sentAt":"2012-05-11T22:25:29Z","receivedAt":"2012-05-11T22:25:29Z","isPatch":false,"sender":{"key":"seb@highlab.com","avatar":"https://gravatar.com/avatar/f7ddd092ba3cf6999434f4d0d2f4b90fd174c2c3851617e8cffc0a2fee47becc?d=mp&s=160"},"body":"Hi folks, I just ran in to a strange behavior with git merge.\n\nThings 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.\n\nNext 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.\n\nThat 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\n\n\n-- \nSebastian Kuzminsky\n"},{"id":"191429","messageId":"ae419d8bbc2b44bfa4c0a7eb421f5037-mfwitten@gmail.com","threadId":"30513","inReplyTo":"9A9AD20F-B316-4DC1-8C6A-E0FC6ED80A61@highlab.com","subject":"Re: surprising behavior from merge","fromName":"Michael Witten","fromEmail":"mfwitten@gmail.com","sentAt":null,"receivedAt":"2012-05-11T23:44:53Z","isPatch":false,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"On Fri, 11 May 2012 16:25:29 -0600, Sebastian Kuzminsky wrote:\n\n> Hi folks, I just ran in to a strange behavior with git merge.\n>\n> Things start out with two branches (let's call them 'master' and\n> 'other') pointing at a particular commit. In master I commit a\n> small one-line change, then make a second commit that adds some\n> stuff just after the line changed in the previous commit. In the\n> other branch, i cherry-pick the second commit from master (the\n> one that adds the new stuff). The cherry-pick succeeds, despite\n> the fuzzy context. So far, so good.\n>\n> Next I try to merge other into master. I expected it to notice\n> there was nothing to do and leave the master tree unchanged,\n> but it applied the \"add new stuff\" patch to master (even though\n> that patch is already in master) and made a commit from that. So\n> it silently did the wrong thing, and now the file contains two\n> copies of stuff I added.\n>\n> That is a simplified version of what happened, in my real repo\n> there were several (unrelated and unimportant) commits on both\n> master and the other branch. When the surprising double-add\n> happened, i simplified the repo to remove distractions.\n> The simplified repo is here if anyone wants to inspect it:\n> https://github.com/SebKuzminsky/merge-problem\n\nIt would obviously be helpful to supply:\n\n  * Explicit commands that anyone on the list can try and discuss.\n    For example:\n\n      git init repo\n      cd repo\n      echo a  > a; git add a; git commit -m 'small one-line change'\n      echo b >> a; git commit -am 'adds some stuff after'\n      ...\n\n  * Expected behavior from those commands.\n\n  * Actual behavior from those commands.\n\nIn other words, rather than burdening people with the task of\nconstructing a mental picture of what you have done, you should\nshow them as directly and precisely as possible; in this way,\npeople can go about the business of discussing your issue much\nmore quickly and, most importantly, PRECISELY.\n\nSincerely,\nMichael Witten\n"},{"id":"191430","messageId":"4FADA967.10808@highlab.com","threadId":"30513","inReplyTo":"ae419d8bbc2b44bfa4c0a7eb421f5037-mfwitten@gmail.com","subject":"Re: surprising behavior from merge","fromName":"Sebastian Kuzminsky","fromEmail":"seb@highlab.com","sentAt":"2012-05-12T00:05:59Z","receivedAt":"2012-05-12T00:05:59Z","isPatch":false,"sender":{"key":"seb@highlab.com","avatar":"https://gravatar.com/avatar/f7ddd092ba3cf6999434f4d0d2f4b90fd174c2c3851617e8cffc0a2fee47becc?d=mp&s=160"},"body":"On 05/11/2012 05:57 PM, Michael Witten wrote:\n> On Fri, 11 May 2012 16:25:29 -0600, Sebastian Kuzminsky wrote:\n>\n>> The simplified repo is here if anyone wants to inspect it:\n>> https://github.com/SebKuzminsky/merge-problem\n...\n\n> In other words, rather than burdening people with the task of\n> constructing a mental picture of what you have done, you should\n> show them as directly and precisely as possible; in this way,\n> people can go about the business of discussing your issue much\n> more quickly and, most importantly, PRECISELY.\n>\n\nAh, I had intended the extremely tiny git repo I linked to to provide \nthe info in the most concise way possible.  The surprising behaviour \nhappened at the final commit in the repo, which was made by 'git merge \nother'.\n\nI can email a list of commands to reproduce the issue later tonight if \nthat would make anything clearer.\n\n\n-- \nSebastian Kuzminsky\n"},{"id":"191431","messageId":"4FADCA05.60109@blizzard.com","threadId":"30513","inReplyTo":"4FADA967.10808@highlab.com","subject":"Re: surprising behavior from merge","fromName":"Illia Bobyr","fromEmail":"ibobyr@blizzard.com","sentAt":"2012-05-12T02:25:09Z","receivedAt":"2012-05-12T02:25:09Z","isPatch":false,"sender":{"key":"ibobyr@blizzard.com","avatar":null},"body":"On 5/11/2012 5:05 PM, Sebastian Kuzminsky wrote:\n> On 05/11/2012 05:57 PM, Michael Witten wrote:\n>> On Fri, 11 May 2012 16:25:29 -0600, Sebastian Kuzminsky wrote:\n>>\n>>> The simplified repo is here if anyone wants to inspect it:\n>>> https://github.com/SebKuzminsky/merge-problem\n> ...\n>\n>> In other words, rather than burdening people with the task of\n>> constructing a mental picture of what you have done, you should\n>> show them as directly and precisely as possible; in this way,\n>> people can go about the business of discussing your issue much\n>> more quickly and, most importantly, PRECISELY.\n>>\n>\n> Ah, I had intended the extremely tiny git repo I linked to to provide \n> the info in the most concise way possible.  The surprising behaviour \n> happened at the final commit in the repo, which was made by 'git merge \n> other'.\n>\n> I can email a list of commands to reproduce the issue later tonight if \n> that would make anything clearer.\n\nThe repository you provided is actually quite simple and clear, though I \nhave no idea why this might be happening.  Or if it is an expected behavior.\n\nAt the same time if you provide a list of command if someone will be \nfixing this they may server as an automated test.  Git has a lot of them.\n\n--\nIllia Bobyr\n"},{"id":"191515","messageId":"8F6454B6-5C93-45AA-8AB0-881FEEE22848@highlab.com","threadId":"30513","inReplyTo":"4FADCA05.60109@blizzard.com","subject":"Re: surprising behavior from merge","fromName":"Sebastian Kuzminsky","fromEmail":"seb@highlab.com","sentAt":"2012-05-14T18:14:21Z","receivedAt":"2012-05-14T18:14:21Z","isPatch":false,"sender":{"key":"seb@highlab.com","avatar":"https://gravatar.com/avatar/f7ddd092ba3cf6999434f4d0d2f4b90fd174c2c3851617e8cffc0a2fee47becc?d=mp&s=160"},"body":"Here's a little script that reproduces the problem:\n\n-----\n#!/bin/bash\nset -e\n\nif [ -e git-merge-problem ]; then\n    echo \"'git-merge-problem' exists, not running test!\"\n    exit 1\nfi\n\nmkdir git-merge-problem\ncd git-merge-problem\ngit init\n\necho \"first line\" > myfile\necho \"second line\" >> myfile\necho \"\" >> myfile\necho \"next to last line\" >> myfile\necho \"final line\" >> myfile\ngit add myfile\ngit commit -m 'initial commit of myfile'\n\ngit branch other\n\nsed -i -e 's/second line/this line is in the context of the crucial patch/' myfile\ngit add myfile\ngit commit -m 'change context for crucial patch'\n\nsed -i -e 's/^$/\\nthis line is added only once, but in two branches\\n/' myfile\ngit add myfile\ngit commit -m 'add a line'\n\ngit tag add-a-line\n\ngit checkout other\ngit cherry-pick -x add-a-line\n\ngit checkout master\n\ngit merge other\n\nNUM_LINES=$(grep 'added only once' myfile | wc -l)\nif [ $NUM_LINES -eq 2 ]; then\n    echo \"FAIL!  the merge added the line twice\"\n    cat myfile\n    exit 1\nelif [ $NUM_LINES -ne 1 ]; then\n    echo \"FAIL!  the merge added the line a strange number of times ($NUM_LINES)\"\n    exit 1\nfi\n\necho \"PASS!  the merge added the line just once!\"\nexit 0\n-----\n\n\n\nOn May 11, 2012, at 20:25 , Illia Bobyr wrote:\n\n> On 5/11/2012 5:05 PM, Sebastian Kuzminsky wrote:\n>> On 05/11/2012 05:57 PM, Michael Witten wrote:\n>>> On Fri, 11 May 2012 16:25:29 -0600, Sebastian Kuzminsky wrote:\n>>> \n>>>> The simplified repo is here if anyone wants to inspect it:\n>>>> https://github.com/SebKuzminsky/merge-problem\n>> ...\n>> \n>>> In other words, rather than burdening people with the task of\n>>> constructing a mental picture of what you have done, you should\n>>> show them as directly and precisely as possible; in this way,\n>>> people can go about the business of discussing your issue much\n>>> more quickly and, most importantly, PRECISELY.\n>>> \n>> \n>> Ah, I had intended the extremely tiny git repo I linked to to provide \n>> the info in the most concise way possible.  The surprising behaviour \n>> happened at the final commit in the repo, which was made by 'git merge \n>> other'.\n>> \n>> I can email a list of commands to reproduce the issue later tonight if \n>> that would make anything clearer.\n> \n> The repository you provided is actually quite simple and clear, though I \n> have no idea why this might be happening.  Or if it is an expected behavior.\n> \n> At the same time if you provide a list of command if someone will be \n> fixing this they may server as an automated test.  Git has a lot of them.\n> \n> --\n> Illia Bobyr\n\n-- \nSebastian Kuzminsky\n"}]}