* [Question]: Question about "cherry-pick" internal
@ 2022-08-04 1:25 Wang, Lei
2022-08-07 16:48 ` Chris Torek
0 siblings, 1 reply; 3+ messages in thread
From: Wang, Lei @ 2022-08-04 1:25 UTC (permalink / raw
To: git@vger.kernel.org
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Question]: Question about "cherry-pick" internal
2022-08-04 1:25 [Question]: Question about "cherry-pick" internal Wang, Lei
@ 2022-08-07 16:48 ` Chris Torek
2022-08-08 3:27 ` Wang, Lei
0 siblings, 1 reply; 3+ messages in thread
From: Chris Torek @ 2022-08-07 16:48 UTC (permalink / raw
To: Wang, Lei; +Cc: git@vger.kernel.org
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Question]: Question about "cherry-pick" internal
2022-08-07 16:48 ` Chris Torek
@ 2022-08-08 3:27 ` Wang, Lei
0 siblings, 0 replies; 3+ messages in thread
From: Wang, Lei @ 2022-08-08 3:27 UTC (permalink / raw
To: Chris Torek; +Cc: git@vger.kernel.org
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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2022-08-08 3:27 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-08-04 1:25 [Question]: Question about "cherry-pick" internal Wang, Lei
2022-08-07 16:48 ` Chris Torek
2022-08-08 3:27 ` Wang, Lei
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).