Re: Cherry picking instead of merges.

From: Björn Steinbrink <b.steinbrink@gmx.de>
Date: Jul 4, 2008, 00:10 UTC
Message-ID: <20080704001003.GA19053@atjola.homenet>
In-Reply-To: <20080703223949.GA23092@old.davidb.org>

On 2008.07.03 15:39:49 -0700, David Brown wrote:

Show 10 quoted lines

> On Thu, Jul 03, 2008 at 02:18:53PM -0700, Linus Torvalds wrote:
>
>> End result: you have a nice merge with nice history that actually
>> converges at a common point, but you effectively did the merge
>> resolution one commit at a time with cherry-picking (or "git rebase",
>> which is obviously just a convenient shorthand for cherry-picking
>> everything).
>
> I'm still not clear how the one-commit-at-a-time resolution gets
> recorded anywhere (except in the cherry-picking branch).

They don't get recorded. Git does not store how merges happened in some diffs or whatever, it just stores the end result. So what Linus suggested was to reuse the end result that you already have to create the merge commit.

Say you have 5 commits like this:

  A---B---C
   \
    D---E

Now there are two ways to get the changes from D and E ontop of C. The first one is cherry-picking, which leads to:

  A---B---C---D'---E'
   \
    D---E

The other one is merging:

  A---B---C---M
   \         /
    D---E---/

Of course, you should end up with the same tree either way. It's just a different way of getting towards that final state. So commit E' and commit M, while different commits, would point to the same tree object.

Now if you want to create that merge commit M, and already have E' (like you do, as you already did all those cherry-picks), you can use what Linus suggested. You start the merge, ignore any conflicts and just tell git to use the tree that E' is pointing to instead.

Björn