{"thread":{"id":"58264","subject":"[Question]: Question about \"cherry-pick\" internal","startedAt":"2022-08-04T01:25:08Z","lastAt":"2022-08-08T03:27:48Z","messageCount":3,"participants":["Wang, Lei","Chris Torek"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"460585","messageId":"e564b1e3-0f34-dce3-400d-439a40ec4d48@intel.com","threadId":"58264","inReplyTo":null,"subject":"[Question]: Question about \"cherry-pick\" internal","fromName":"Wang, Lei","fromEmail":"lei4.wang@intel.com","sentAt":"2022-08-04T01:25:02Z","receivedAt":"2022-08-04T01:25:08Z","isPatch":false,"sender":{"key":"lei4.wang@intel.com","avatar":null},"body":"Hi,\n\nI heard that cherry-pick is just a kind of merge, the difference between \nit and the traditional merge is that it treats the parent commit of the \ncommit you want to cherry-pick as the merge-base, then it will diff both \nthe current branch with the parent and the commit you want to \ncherry-pick with the parent to generate 2 diffs, then it will try to \napply these 2 diffs to the parent commit. If the diff modified the same \nline, then a conflict occurs.\n\nIf the above is true, but why when I cherry-picked a commit, a conflict \noccurs even the 2 diffs didn't modify the same line, they modified the \ntwo consecutive lines (line n and line n + 1), so what can be the \npotential reason for this?\n\nLooking forward to your valuable comments!\n\n-- \nBR,\nLei\n\n"},{"id":"460791","messageId":"CAPx1Gvd9xLdJaWiTN1MrktyEMfKmAjTx9zxOVcOnRv7r9n_ZiQ@mail.gmail.com","threadId":"58264","inReplyTo":"e564b1e3-0f34-dce3-400d-439a40ec4d48@intel.com","subject":"Re: [Question]: Question about \"cherry-pick\" internal","fromName":"Chris Torek","fromEmail":"chris.torek@gmail.com","sentAt":"2022-08-07T16:48:27Z","receivedAt":"2022-08-07T16:48:44Z","isPatch":false,"sender":{"key":"chris.torek@gmail.com","avatar":"https://avatars.githubusercontent.com/u/16826774?v=4"},"body":"On Wed, Aug 3, 2022 at 6:42 PM Wang, Lei <lei4.wang@intel.com> wrote:\n> I heard that cherry-pick is just a kind of merge, the difference between\n> it and the traditional merge is that it treats the parent commit of the\n> commit you want to cherry-pick as the merge-base ...\n\nThis is indeed the case.\n\n> [During merging:] If the [two] diff[s] modified the same\n> line, then a conflict occurs.\n\nThis is also true—but it's not the whole story.\n\n> If the above is true, but why when I cherry-picked a commit, a conflict\n> occurs even the 2 diffs didn't modify the same line, they modified the\n> two consecutive lines (line n and line n + 1), so what can be the\n> potential reason for this?\n\nIn any merge, if the two sides modify *adjacent* lines—as is the\ncase here—that, too, is considered a conflict (at least Git considers\nit as one; not all merge algorithms do that).\n\nNote that if the two diffs modify the same line(s) in the *same way*—\ne.g., both add the same text or delete the same text—Git will take\nonly *one copy* of the change, without calling it a conflict. In some\ncases this may be incorrect: consider. e.g., merging the debits and\ncredits in a series of accounting records, where the dollar amounts\nare identical, but the transactions are different.  If Alice spent $5\nand Bob spent $5, the correct result is not that \"$5 total was spent\"\nbut rather $10.\n\nStill, for the kinds of tasks *Git* is asked to merge, this is normally\nthe correct result, so it is the result Git produces.\n\nGit is a tool—or rather, a set of tools—and its automated work is\nnever a substitute for expert evaluation.  You, the user, must do\nsome work here as well, to make sure that what Git did is in fact\ncorrect for your particular situation.\n\nChris\n"},{"id":"460800","messageId":"002aad57-9389-abfd-207a-3c02b47cdbf0@intel.com","threadId":"58264","inReplyTo":"CAPx1Gvd9xLdJaWiTN1MrktyEMfKmAjTx9zxOVcOnRv7r9n_ZiQ@mail.gmail.com","subject":"Re: [Question]: Question about \"cherry-pick\" internal","fromName":"Wang, Lei","fromEmail":"lei4.wang@intel.com","sentAt":"2022-08-08T03:27:42Z","receivedAt":"2022-08-08T03:27:48Z","isPatch":false,"sender":{"key":"lei4.wang@intel.com","avatar":null},"body":"You solved my problem, many thanks!\n\nBR,\nLei\n\nOn 8/8/2022 12:48 AM, Chris Torek wrote:\n> On Wed, Aug 3, 2022 at 6:42 PM Wang, Lei <lei4.wang@intel.com> wrote:\n>> I heard that cherry-pick is just a kind of merge, the difference between\n>> it and the traditional merge is that it treats the parent commit of the\n>> commit you want to cherry-pick as the merge-base ...\n> This is indeed the case.\n>\n>> [During merging:] If the [two] diff[s] modified the same\n>> line, then a conflict occurs.\n> This is also true—but it's not the whole story.\n>\n>> If the above is true, but why when I cherry-picked a commit, a conflict\n>> occurs even the 2 diffs didn't modify the same line, they modified the\n>> two consecutive lines (line n and line n + 1), so what can be the\n>> potential reason for this?\n> In any merge, if the two sides modify *adjacent* lines—as is the\n> case here—that, too, is considered a conflict (at least Git considers\n> it as one; not all merge algorithms do that).\n>\n> Note that if the two diffs modify the same line(s) in the *same way*—\n> e.g., both add the same text or delete the same text—Git will take\n> only *one copy* of the change, without calling it a conflict. In some\n> cases this may be incorrect: consider. e.g., merging the debits and\n> credits in a series of accounting records, where the dollar amounts\n> are identical, but the transactions are different.  If Alice spent $5\n> and Bob spent $5, the correct result is not that \"$5 total was spent\"\n> but rather $10.\n>\n> Still, for the kinds of tasks *Git* is asked to merge, this is normally\n> the correct result, so it is the result Git produces.\n>\n> Git is a tool—or rather, a set of tools—and its automated work is\n> never a substitute for expert evaluation.  You, the user, must do\n> some work here as well, to make sure that what Git did is in fact\n> correct for your particular situation.\n>\n> Chris\n"}]}