On 24.1.2019 11.13, Edward Welbourne wrote: >> A cherry-pick takes the diff involved in one commit and patches >> another check-out with it. A merge uses the digraph of commits in >> sophisticated ways; a cherry-pick does not.
Kari Oikarinen (24 January 2019 10:33) > Quoting man page for git-cherry-pick: https://git-scm.com/docs/git-cherry-pick > > "For conflicting paths, the index file records up to three versions, > as described in the "TRUE MERGE" section of git-merge[1]. The working > tree files will include a description of the conflict bracketed by the > usual conflict markers <<<<<<< and >>>>>>>." > > It is similar enough that it actually refers to the same section of > documentation! I stand corrected. Time to re-read the cherry-pick docs. My apologies to Allan for my misunderstanding. > But it doesn't actually create a new common ancestor for the > commits. So every further cherry-pick can still hit the same > conflict. Instead of being resolved by the merge, there's an unbounded > amount of time that different people will hit it and need to resolve > it. That's a good point. Eddy. _______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
