From: Wang, Lei Date: Mon, 08 Aug 2022 03:27:42 GMT Subject: Re: [Question]: Question about "cherry-pick" internal Message-ID: <002aad57-9389-abfd-207a-3c02b47cdbf0@intel.com> In-Reply-To: You solved my problem, many thanks! BR, Lei On 8/8/2022 12:48 AM, Chris Torek wrote: > On Wed, Aug 3, 2022 at 6:42 PM Wang, Lei wrote: >> I heard that cherry-pick is just a kind of merge, the difference between >> it and the traditional merge is that it treats the parent commit of the >> commit you want to cherry-pick as the merge-base ... > This is indeed the case. > >> [During merging:] If the [two] diff[s] modified the same >> line, then a conflict occurs. > This is also true—but it's not the whole story. > >> If the above is true, but why when I cherry-picked a commit, a conflict >> occurs even the 2 diffs didn't modify the same line, they modified the >> two consecutive lines (line n and line n + 1), so what can be the >> potential reason for this? > In any merge, if the two sides modify *adjacent* lines—as is the > case here—that, too, is considered a conflict (at least Git considers > it as one; not all merge algorithms do that). > > Note that if the two diffs modify the same line(s) in the *same way*— > e.g., both add the same text or delete the same text—Git will take > only *one copy* of the change, without calling it a conflict. In some > cases this may be incorrect: consider. e.g., merging the debits and > credits in a series of accounting records, where the dollar amounts > are identical, but the transactions are different. If Alice spent $5 > and Bob spent $5, the correct result is not that "$5 total was spent" > but rather $10. > > Still, for the kinds of tasks *Git* is asked to merge, this is normally > the correct result, so it is the result Git produces. > > Git is a tool—or rather, a set of tools—and its automated work is > never a substitute for expert evaluation. You, the user, must do > some work here as well, to make sure that what Git did is in fact > correct for your particular situation. > > Chris