[Development] Proposal: New branch model

Kari Oikarinen kari.oikarinen at qt.io
Thu Jan 24 10:33:26 CET 2019

On 24.1.2019 11.13, Edward Welbourne wrote:
> 23.01.2019, 21:38, "Alex Blasche" <alexander.blasche at qt.io>:
>>>> At the end of the day each cherry-pick is a merge too
> Merges and cherry-picks have a certain amount in common, but they are
> not the same thing at all.
>>>> and they can conflict too. The conflict resolution process is still
>>>> the same. if everything is conflict free then a git merge would be
>>>> no more difficult than a cherry-pick.
> This is true.
> On Mittwoch, 23. Januar 2019 19:43:06 CET Konstantin Tokarev wrote:
>>> And when conflicts are present, cherry-picking N patches may result in N
>>> times more work than merge in worst case (and same amount of work in the
>>> best case)
> Allan Sandfeld Jensen (23 January 2019 23:05)
>> More than that. Once you have had cherry-pick only for a while git will be
>> unable to find useful common ancestors for the changes, and will be unable to
>> do smart three-way merging of cherry-picks,
> OK, now you're just engaging in ill-informed FUD.
> Cherry-picks do not involve any three-way anything.
> You clearly do not understand the difference between merging and
> cherry-picking.
> 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.

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

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.


More information about the Development mailing list