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

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

[Wang, Lei]

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

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

[Chris Torek]

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

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

[Wang, Lei]

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 <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