threads / discuss / 58264

[Question]: Question about "cherry-pick" internal

Subject: [Question]: Question about "cherry-pick" internal

## tl;dr

3 messages between Aug 4, 2022 and Aug 8, 2022.

replies: 2people: 2as markdown or json

Wang, Lei· Aug 4, 2022, 01:25 UTC · lore
Hi,

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, then it will diff both the current branch with the parent and the commit you want to cherry-pick with the parent to generate 2 diffs, then it will try to apply these 2 diffs to the parent commit. If the diff modified the same line, then a conflict occurs.

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?

Looking forward to your valuable comments!
-- 
BR,
Lei
Chris Torek· Aug 7, 2022, 16:48 UTC · re: Wang, Lei · lore

Re: [Question]: Question about "cherry-pick" internal

On Wed, Aug 3, 2022 at 6:42 PM Wang, Lei <lei4.wang@intel.com> 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
Wang, Lei· Aug 8, 2022, 03:27 UTC · re: Chris Torek · lore

Re: [Question]: Question about "cherry-pick" internal

You solved my problem, many thanks!

BR, Lei

On 8/8/2022 12:48 AM, Chris Torek wrote:
Show 36 quoted lines
> On Wed, Aug 3, 2022 at 6:42 PM Wang, Lei <lei4.wang@intel.com> 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

← back to recent threads