* bugreport: Wrong binary file content after cherry-pick @ 2020-05-13 8:47 Chunlin Zhang 2020-05-13 16:15 ` Junio C Hamano 0 siblings, 1 reply; 3+ messages in thread From: Chunlin Zhang @ 2020-05-13 8:47 UTC (permalink / raw) To: git git version: after v2.21.0 can reproduce this bug reproduce steps: git clone https://github.com/zhangchunlin/gitbug cd gitbug git cherry-pick dev Then there will be a conflict with the cherry-pick, but if you run "md5sum *", will get: 6f96c8bc9e3df2f6fef1ecbb09f218f6 ICS_usc_any_any_9.1.5_8871.uscc_261_130664_2048-release.apk 6f96c8bc9e3df2f6fef1ecbb09f218f6 ICS_usc_any_any_9.8.0_b2cbd84d94.b2cbd84_297_131010_2048-release.apk The second file get a wrong file content. 3 related files md5: 6f96c8bc9e3df2f6fef1ecbb09f218f6 ICS_usc_any_any_9.1.5_8871.uscc_261_130664_2048-release.apk d1bdd852b32c09ec93a5494afb3c67e7 ICS_usc_any_any_9.1.5_8871.uscc_266_130703_2048-release.apk b2c50a9d7d488aa0b62ec7e68706ea85 ICS_usc_any_any_9.8.0_b2cbd84d94.b2cbd84_297_131010_2048-release.apk I use git bisect to found the commit which cause this problem: https://github.com/git/git/commit/48c9cb9d6d058bcf18e931a1ed0d88792bb506c9 ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: bugreport: Wrong binary file content after cherry-pick 2020-05-13 8:47 bugreport: Wrong binary file content after cherry-pick Chunlin Zhang @ 2020-05-13 16:15 ` Junio C Hamano 2020-05-13 23:21 ` Elijah Newren 0 siblings, 1 reply; 3+ messages in thread From: Junio C Hamano @ 2020-05-13 16:15 UTC (permalink / raw) To: Elijah Newren; +Cc: git, Chunlin Zhang Chunlin Zhang <zhangchunlin@gmail.com> writes: > git version: after v2.21.0 can reproduce this bug > > reproduce steps: > git clone https://github.com/zhangchunlin/gitbug > cd gitbug > git cherry-pick dev > > Then there will be a conflict with the cherry-pick, but if you run > "md5sum *", will get: > 6f96c8bc9e3df2f6fef1ecbb09f218f6 > ICS_usc_any_any_9.1.5_8871.uscc_261_130664_2048-release.apk > 6f96c8bc9e3df2f6fef1ecbb09f218f6 > ICS_usc_any_any_9.8.0_b2cbd84d94.b2cbd84_297_131010_2048-release.apk > > The second file get a wrong file content. > 3 related files md5: > 6f96c8bc9e3df2f6fef1ecbb09f218f6 > ICS_usc_any_any_9.1.5_8871.uscc_261_130664_2048-release.apk > d1bdd852b32c09ec93a5494afb3c67e7 > ICS_usc_any_any_9.1.5_8871.uscc_266_130703_2048-release.apk > b2c50a9d7d488aa0b62ec7e68706ea85 > ICS_usc_any_any_9.8.0_b2cbd84d94.b2cbd84_297_131010_2048-release.apk > > I use git bisect to found the commit which cause this problem: > https://github.com/git/git/commit/48c9cb9d6d058bcf18e931a1ed0d88792bb506c9 That's Elijah's 48c9cb9d (merge-recursive: improve rename/rename(1to2)/add[/add] handling, 2018-11-07) The history Chunlin's repository has is a three-commit single strand of pearls; each commit's tree records only a single blob: * 'master' that has "uscc_261" file whose contents is f98ab07. * another commit on top of 'master' that renames "uscc_261" to "uscc_266" with some modifications; the contents after the modification is 3f71e11. * 'dev' that is a child of the above, which again renames it to a name without "uscc" in it, whose contents is 4f19f66. As the .apk file is binary that cannot be merged textually, it is perfectly fine for "cherry-pick dev" to leave the index unmerged. The index has f98ab07 at uscc_261, stage #2 (ours) 3f71e11 at uscc_266, stage #1 (common) 4f19f66 at the name in 'dev', stage #3 (theirs) which is perfectly expected. In the working tree, we see "uscc_261" with contents f98ab07 (i.e. "ours") a file with the name in 'dev', with contents f98ab07 The latter is unexpected to me. ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: bugreport: Wrong binary file content after cherry-pick 2020-05-13 16:15 ` Junio C Hamano @ 2020-05-13 23:21 ` Elijah Newren 0 siblings, 0 replies; 3+ messages in thread From: Elijah Newren @ 2020-05-13 23:21 UTC (permalink / raw) To: Junio C Hamano; +Cc: Git Mailing List, Chunlin Zhang On Wed, May 13, 2020 at 9:15 AM Junio C Hamano <gitster@pobox.com> wrote: > > Chunlin Zhang <zhangchunlin@gmail.com> writes: > > > git version: after v2.21.0 can reproduce this bug > > > > reproduce steps: > > git clone https://github.com/zhangchunlin/gitbug > > cd gitbug > > git cherry-pick dev > > > > Then there will be a conflict with the cherry-pick, but if you run > > "md5sum *", will get: > > 6f96c8bc9e3df2f6fef1ecbb09f218f6 > > ICS_usc_any_any_9.1.5_8871.uscc_261_130664_2048-release.apk > > 6f96c8bc9e3df2f6fef1ecbb09f218f6 > > ICS_usc_any_any_9.8.0_b2cbd84d94.b2cbd84_297_131010_2048-release.apk > > > > The second file get a wrong file content. > > 3 related files md5: > > 6f96c8bc9e3df2f6fef1ecbb09f218f6 > > ICS_usc_any_any_9.1.5_8871.uscc_261_130664_2048-release.apk > > d1bdd852b32c09ec93a5494afb3c67e7 > > ICS_usc_any_any_9.1.5_8871.uscc_266_130703_2048-release.apk > > b2c50a9d7d488aa0b62ec7e68706ea85 > > ICS_usc_any_any_9.8.0_b2cbd84d94.b2cbd84_297_131010_2048-release.apk > > > > I use git bisect to found the commit which cause this problem: > > https://github.com/git/git/commit/48c9cb9d6d058bcf18e931a1ed0d88792bb506c9 > > That's Elijah's 48c9cb9d (merge-recursive: improve > rename/rename(1to2)/add[/add] handling, 2018-11-07) > > The history Chunlin's repository has is a three-commit single strand > of pearls; each commit's tree records only a single blob: > > * 'master' that has "uscc_261" file whose contents is f98ab07. > > * another commit on top of 'master' that renames "uscc_261" to > "uscc_266" with some modifications; the contents after the > modification is 3f71e11. > > * 'dev' that is a child of the above, which again renames it to a > name without "uscc" in it, whose contents is 4f19f66. > > As the .apk file is binary that cannot be merged textually, it is > perfectly fine for "cherry-pick dev" to leave the index unmerged. > The index has > > f98ab07 at uscc_261, stage #2 (ours) > 3f71e11 at uscc_266, stage #1 (common) > 4f19f66 at the name in 'dev', stage #3 (theirs) > > which is perfectly expected. > > In the working tree, we see > > "uscc_261" with contents f98ab07 (i.e. "ours") > a file with the name in 'dev', with contents f98ab07 > > The latter is unexpected to me. rename/rename(1to2) is unique among our conflict types in that it attempts to copy the as-merged-as-possible content to two locations in the working copy. Problem is, as-merged-as-possible for a binary file means randomly picking one of the two versions (okay, not quite random -- it always picks the copy from HEAD). For rename/rename(1to2) where we have two copies of the contents in the working tree at each of the paths, it'd make more sense to keep two different versions of the file in the working tree. I'll send in a patch soon. ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2020-05-13 23:21 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-05-13 8:47 bugreport: Wrong binary file content after cherry-pick Chunlin Zhang 2020-05-13 16:15 ` Junio C Hamano 2020-05-13 23:21 ` Elijah Newren
Code repositories for project(s) associated with this public inbox https://80x24.org/mirrors/git.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).