Re: cherry picking and merge

From: Nico Williams <nico@cryptonector.com>
Date: Aug 1, 2014, 22:00 UTC
Message-ID: <CAK3OfOiLRpz7n7rCQZ7ixahoQyt=xywnDewtc+KCT_5LhYEC7A@mail.gmail.com>
In-Reply-To: <xmqq4mxvvqan.fsf@gitster.dls.corp.google.com>

On Fri, Aug 1, 2014 at 4:44 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 15 quoted lines

> Nico Williams <nico@cryptonector.com> writes:
>
>> Cherry-picks should record two parents, like merges.
>
> No.
>
> It is OK to record where it came from, and we let you do so with the
> "-x" option.
>
> But the "where it came from" commit is very different from being
> parent, which implies "all the history behind it".  The whole point
> of a cherry-pick is that you do not want to grab the changes behind
> the commit you are cherry-picking and you want the _change_ the
> cherry-picked commit (and that commit alone) brings in.  It should
> never record "two parents, like merges."

I didn't mean to imply all that. s/parent/where it came from/, but -x edits the commit message, not the metadata...

The point remains: to do what the OP wants git merge would have to be able to notice that a given commit was cherry-picked from the other branch, and what commit it was on that other branch, and right now the only place where that information is available is in the reflog. Recording that metadata somewhere in the commit resulting from the cherry-pick would be better.

Nico --