{"thread":{"id":"53459","subject":"bugreport: Wrong binary file content after cherry-pick","startedAt":"2020-05-13T08:48:11Z","lastAt":"2020-05-13T23:21:52Z","messageCount":3,"participants":["Chunlin Zhang","Junio C Hamano","Elijah Newren"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"397706","messageId":"CAG2rzA=c8bGD6A_8kKCdz+UABjed9W6mSJYjLhYckbsXiFe4CQ@mail.gmail.com","threadId":"53459","inReplyTo":null,"subject":"bugreport: Wrong binary file content after cherry-pick","fromName":"Chunlin Zhang","fromEmail":"zhangchunlin@gmail.com","sentAt":"2020-05-13T08:47:56Z","receivedAt":"2020-05-13T08:48:11Z","isPatch":false,"sender":{"key":"zhangchunlin@gmail.com","avatar":"https://gravatar.com/avatar/3767134496b3344f758bafc6cf8b5be08e212193fcaaff9dc819b732b5a0c476?d=mp&s=160"},"body":"git version: after v2.21.0 can reproduce this bug\n\nreproduce steps:\ngit clone https://github.com/zhangchunlin/gitbug\ncd gitbug\ngit cherry-pick dev\n\nThen there will be a conflict with the cherry-pick, but if you run\n\"md5sum *\", will get:\n6f96c8bc9e3df2f6fef1ecbb09f218f6\nICS_usc_any_any_9.1.5_8871.uscc_261_130664_2048-release.apk\n6f96c8bc9e3df2f6fef1ecbb09f218f6\nICS_usc_any_any_9.8.0_b2cbd84d94.b2cbd84_297_131010_2048-release.apk\n\nThe second file get a wrong file content.\n3 related files md5:\n6f96c8bc9e3df2f6fef1ecbb09f218f6\nICS_usc_any_any_9.1.5_8871.uscc_261_130664_2048-release.apk\nd1bdd852b32c09ec93a5494afb3c67e7\nICS_usc_any_any_9.1.5_8871.uscc_266_130703_2048-release.apk\nb2c50a9d7d488aa0b62ec7e68706ea85\nICS_usc_any_any_9.8.0_b2cbd84d94.b2cbd84_297_131010_2048-release.apk\n\nI use git bisect to found the commit which cause this problem:\nhttps://github.com/git/git/commit/48c9cb9d6d058bcf18e931a1ed0d88792bb506c9\n"},{"id":"397718","messageId":"xmqqsgg3vmiz.fsf@gitster.c.googlers.com","threadId":"53459","inReplyTo":"CAG2rzA=c8bGD6A_8kKCdz+UABjed9W6mSJYjLhYckbsXiFe4CQ@mail.gmail.com","subject":"Re: bugreport: Wrong binary file content after cherry-pick","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-05-13T16:15:48Z","receivedAt":"2020-05-13T16:15:59Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Chunlin Zhang <zhangchunlin@gmail.com> writes:\n\n> git version: after v2.21.0 can reproduce this bug\n>\n> reproduce steps:\n> git clone https://github.com/zhangchunlin/gitbug\n> cd gitbug\n> git cherry-pick dev\n>\n> Then there will be a conflict with the cherry-pick, but if you run\n> \"md5sum *\", will get:\n> 6f96c8bc9e3df2f6fef1ecbb09f218f6\n> ICS_usc_any_any_9.1.5_8871.uscc_261_130664_2048-release.apk\n> 6f96c8bc9e3df2f6fef1ecbb09f218f6\n> ICS_usc_any_any_9.8.0_b2cbd84d94.b2cbd84_297_131010_2048-release.apk\n>\n> The second file get a wrong file content.\n> 3 related files md5:\n> 6f96c8bc9e3df2f6fef1ecbb09f218f6\n> ICS_usc_any_any_9.1.5_8871.uscc_261_130664_2048-release.apk\n> d1bdd852b32c09ec93a5494afb3c67e7\n> ICS_usc_any_any_9.1.5_8871.uscc_266_130703_2048-release.apk\n> b2c50a9d7d488aa0b62ec7e68706ea85\n> ICS_usc_any_any_9.8.0_b2cbd84d94.b2cbd84_297_131010_2048-release.apk\n>\n> I use git bisect to found the commit which cause this problem:\n> https://github.com/git/git/commit/48c9cb9d6d058bcf18e931a1ed0d88792bb506c9\n\nThat's Elijah's 48c9cb9d (merge-recursive: improve\nrename/rename(1to2)/add[/add] handling, 2018-11-07)\n\nThe history Chunlin's repository has is a three-commit single strand\nof pearls; each commit's tree records only a single blob:\n\n * 'master' that has \"uscc_261\" file whose contents is f98ab07.\n\n * another commit on top of 'master' that renames \"uscc_261\" to\n   \"uscc_266\" with some modifications; the contents after the\n   modification is 3f71e11.\n\n * 'dev' that is a child of the above, which again renames it to a\n   name without \"uscc\" in it, whose contents is 4f19f66.\n\nAs the .apk file is binary that cannot be merged textually, it is\nperfectly fine for \"cherry-pick dev\" to leave the index unmerged.\nThe index has\n\n    f98ab07 at uscc_261, stage #2 (ours)\n    3f71e11 at uscc_266, stage #1 (common)\n    4f19f66 at the name in 'dev', stage #3 (theirs)\n\nwhich is perfectly expected.\n\nIn the working tree, we see \n\n    \"uscc_261\" with contents f98ab07 (i.e. \"ours\")\n    a file with the name in 'dev', with contents f98ab07\n\nThe latter is unexpected to me.\n\n\n\n \n"},{"id":"397792","messageId":"CABPp-BFdDC0LsFUZuwqw2S+L_yFy5gf-QhQebG56FBOAw+wkAg@mail.gmail.com","threadId":"53459","inReplyTo":"xmqqsgg3vmiz.fsf@gitster.c.googlers.com","subject":"Re: bugreport: Wrong binary file content after cherry-pick","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2020-05-13T23:21:39Z","receivedAt":"2020-05-13T23:21:52Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Wed, May 13, 2020 at 9:15 AM Junio C Hamano <gitster@pobox.com> wrote:\n>\n> Chunlin Zhang <zhangchunlin@gmail.com> writes:\n>\n> > git version: after v2.21.0 can reproduce this bug\n> >\n> > reproduce steps:\n> > git clone https://github.com/zhangchunlin/gitbug\n> > cd gitbug\n> > git cherry-pick dev\n> >\n> > Then there will be a conflict with the cherry-pick, but if you run\n> > \"md5sum *\", will get:\n> > 6f96c8bc9e3df2f6fef1ecbb09f218f6\n> > ICS_usc_any_any_9.1.5_8871.uscc_261_130664_2048-release.apk\n> > 6f96c8bc9e3df2f6fef1ecbb09f218f6\n> > ICS_usc_any_any_9.8.0_b2cbd84d94.b2cbd84_297_131010_2048-release.apk\n> >\n> > The second file get a wrong file content.\n> > 3 related files md5:\n> > 6f96c8bc9e3df2f6fef1ecbb09f218f6\n> > ICS_usc_any_any_9.1.5_8871.uscc_261_130664_2048-release.apk\n> > d1bdd852b32c09ec93a5494afb3c67e7\n> > ICS_usc_any_any_9.1.5_8871.uscc_266_130703_2048-release.apk\n> > b2c50a9d7d488aa0b62ec7e68706ea85\n> > ICS_usc_any_any_9.8.0_b2cbd84d94.b2cbd84_297_131010_2048-release.apk\n> >\n> > I use git bisect to found the commit which cause this problem:\n> > https://github.com/git/git/commit/48c9cb9d6d058bcf18e931a1ed0d88792bb506c9\n>\n> That's Elijah's 48c9cb9d (merge-recursive: improve\n> rename/rename(1to2)/add[/add] handling, 2018-11-07)\n>\n> The history Chunlin's repository has is a three-commit single strand\n> of pearls; each commit's tree records only a single blob:\n>\n>  * 'master' that has \"uscc_261\" file whose contents is f98ab07.\n>\n>  * another commit on top of 'master' that renames \"uscc_261\" to\n>    \"uscc_266\" with some modifications; the contents after the\n>    modification is 3f71e11.\n>\n>  * 'dev' that is a child of the above, which again renames it to a\n>    name without \"uscc\" in it, whose contents is 4f19f66.\n>\n> As the .apk file is binary that cannot be merged textually, it is\n> perfectly fine for \"cherry-pick dev\" to leave the index unmerged.\n> The index has\n>\n>     f98ab07 at uscc_261, stage #2 (ours)\n>     3f71e11 at uscc_266, stage #1 (common)\n>     4f19f66 at the name in 'dev', stage #3 (theirs)\n>\n> which is perfectly expected.\n>\n> In the working tree, we see\n>\n>     \"uscc_261\" with contents f98ab07 (i.e. \"ours\")\n>     a file with the name in 'dev', with contents f98ab07\n>\n> The latter is unexpected to me.\n\nrename/rename(1to2) is unique among our conflict types in that it\nattempts to copy the as-merged-as-possible content to two locations in\nthe working copy.  Problem is, as-merged-as-possible for a binary file\nmeans randomly picking one of the two versions (okay, not quite random\n-- it always picks the copy from HEAD).  For rename/rename(1to2) where\nwe have two copies of the contents in the working tree at each of the\npaths, it'd make more sense to keep two different versions of the file\nin the working tree.  I'll send in a patch soon.\n"}]}