That [B C vs C B] should not be the case.
It is important to decide (and understand) what the command means, especially
the difference between a changeset (which is a diff between two commits) and
the content of the commit itself (the snapshot).
so A +(B-A) + (C-B) = C; the former commit A, has been updated by the two
picked changes (B-A) and (C-B) to produce a new result C. It does not matter
which order those changes are applied, the result is the same.
The big "however", is that if the context lines (which were supposedly
unchanged!) overlap past/future changes then the percieved conflict is not on
the changed lines but the method of communicating context. Cherry-pick has
better methods of communicating the context, so can work better at achieving
the pair of asked for changes.
These then have to be worked into the method for specifying the revisions. You
may find that the range of revisions you are picking is more than the single
change set of B from its parent and C from its parent.
You may have added some extended ranges. Do look at the two dot and three dot
notations, along with the caret (^) prefix, and all the cherry-pick examples to
see just how powerful (and easy to misunderstand) it can be. (Aside: I just got
a documentation patch accepted on those very points because of my
misunderstandings and need for clarifications)
The cherry-pick has it's own additional processing of the rev list as far as I
can see. i.e.
" list of ways to spell commits, see gitrevisions(7).
Sets of commits can be passed but no traversal is done by default, as if the
--no-walk option was specified, see git-rev-list(1). "
The critical item there being the --no-walk for lone items.
Philip
----- Original Message -----
From: Elpie Kay
To: Git for human beings
Cc: philipoak...@iee.org
Sent: Monday, September 19, 2016 10:07 AM
Subject: Re: [git-users] How to disable 3way merge for git cherry-pick?
Thanks for you reply.
In that case, 'git cherry-pick B C' and 'git cherry-pick C B' make the file's
contents different.
'git cherry-pick B C' is expected, but someone may run 'git cherry-pick C B'
by mistake.
We want to avoid this mistake. At present it's hard for us to handle this
situation through code-review.
Grateful for any suggestion to this question or to this situation.
在 2016年9月19日星期一 UTC+8下午4:37:30，Philip Oakley写道：
Why do you need the perfectly reasonable (to me) cherry-pick merge to fail?
(comments also added to the SO question)
----- Original Message -----
From: Elpie Kay
To: Git for human beings
Sent: Monday, September 19, 2016 5:24 AM
Subject: [git-users] How to disable 3way merge for git cherry-pick?
Hi All,
Is it possible to disable or not use 3way merge for a cherry-pick, like
git am or git apply?
I asked a question on Stackoverflow,
how-to-raise-a-conflict-for-this-git-cherry-pick, which describes the case.
Thank you.
--
You received this message because you are subscribed to the Google Groups
"Git for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to git-users+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
